Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/bserdar/pomutil

Deal with large Maven projects
https://github.com/bserdar/pomutil

build-tools maven pom

Last synced: about 2 months ago
JSON representation

Deal with large Maven projects

Awesome Lists containing this project

README 

        
Pomutils deals with POM trees. You can



  * Run queries and/or operations on POM trees

  * Generate root POMs to build only the required sub projects of a

    large project based on a build manifest

  * Move common POM fragments into individual XML files, and maintain

    them



Querying and Modifying POM files

--------------------------------



## Querying a POM file



Prints the results of an XPath based on a POM file.



    pomutil  -xp



Example:



Print out the version of a project:



    pomutil pom.xml -xp/project/version



## Check version number sanity accross POM files



Determines artifact cross references in a POM tree, and prints

inconsistencies where a version of the artifact is built, but a

different version of that artifact is referenced in another part of

the tree.



    pomutil  -x



## Print versions of all artifacts in a POM tree



Prints out all artifact names and versions



    pomutil  -p



Each artifact is written in a separate line with the following format:



    groupId:artifactId=version



## Change version number of an artifact in a POM tree



Changes the version number of an artifact in the POM file where it is

defined, and in all POM files where it is referenced.



    pomutil  [-a] -vgroupId:artifactId:version



Sets the version number of `groupId:artifact` to `version`. The `-a`

switch rewrites all poms. Without `-a`, only modified poms are written.



## Bulk change version



    pomutil  -fFile



where `File` is a text file that uses the same format as the `-p` (print

all versions) option.



You can print all versions of a project to a file, then edit that file

to set new version numbers, and use this feature to set version

numbers in bulk:



    pomutil pom.xml -p>versions

    # edit versions file to set the new version numbers

    pomutil pom.xml -fversions



## Find projects in a POM tree depending on an artifact



    pomutil  -dfgroupId:artifactId:version



Lists all the pom files in which `groupId:artifactId:version` appears as

a direct dependency. version can be "`*`", meaning any matching

`groupId:artifactId` will be listed.



## Remove a direct dependency from a POM tree



    pomutil  -drgroupId:artifactId:version



Remove al occurances of `groupId:artifactId:version` from all projects

in the tree. version can be "`*`".



# Partial Builds



It is rarely necessary to build all modules of a large project

containing many submodules. Pomutil can generate root POM files for

such projects based on a build manifest listing the sub modules that

need to be built. The generated POM file build all the modules given

in the build manifest, and all the modules that depend on the modules

in the build set.



## Project structure



Consider an aggregator style root POM listing basic configuration and

all the sub projects:



`code/pom.xml`:



    

      ...

       

          module1

          module2

           ...

          moduleN

       

      ...

    



Every build of this project requires that all the submodules

`module1,...,moduleN` are also built. If our workset is limited to, say,

only `module1`, it is not necessary to rebuild all submodules every

time. What is required is that you build module1 to test/release your

changes, and you build any module that depends on `module1`, so those

can be release as well now that they are using a newer version of

`module1`. To do this, a build manifest is prepared:



`myworkset.xml`:



    

       

          module1

       

    



We also need a definition of all the available modules:



`all.mf.xml`:



    

       

          

             module1

             module1/pom.xml

          

          

             module2

             module2/pom.xml

          

          ...

          

             moduleN

             moduleN/pom.xml

          

       

    



Last, we need to provide a skeleton POM file containing all the

project related configuration we need at the root pom level:



`skel.xml`:



    

       4.0.0.

       autogen

       root

       0

       pom

       autogen

       

         ...

       

       

         ...

       

       

       

    



Note the empty modules element.



Then, running



    pomutil -rmyworkset.xml -lall.mf.xml -opom.xml -sskel.xml



will generate a `pom.xml` file, using `skel.xml` as a baseline, adding

all the modules listed in the build manifest and the modules that are

dependent on that build set.

      

# XMLFrag



Aggregator style Maven projects have some limitations. Most of the

common project information is stored in the root pom, and child

projects inherit from it. It is not possible to modularize such

projects so that sligthly different configurations can be applied for

certain targets. Inheriting from multiple root poms is not allowed, so

sub projects end up overriding things setup in root pom.



Instead of using a root pom, a large project structure can be divided

into individual smaller projects, with fragments of POM files are

stored in a different location. XMLFrag reconstructs POM files using

such fragments.



Move sections of POM files into fragments. For instance:



Original POM file:



    

       ...

       

         

          ...

         

       

       ...



Move dependencies to a fragment:



`fragments/dependencies.frag.xml`:



    

        

         ...

       

    



POM file:



    

       ...

       

       

       

       ...

    



Then, run XMLFrag:



    xmlfrag -ffragments pom.xml



This command inserts the contents of `fragments/dependencies.frag.xml`

into the pom file. It also replaces the fragment comment with hash

information, so that if the fragment is modified, the modifications

are applied to the pom file correctly when `xmlfrag` is run again. If

fragments inserted into the POM file using `xmlfrag` is manually

modified, `xmlfrag` will warn when executed. `-x` switch forces

replacement of the fragments in pom files.