JBossWorld Boston notes, JBoss maven repository, Paul Gier and John Casey
Good news, the jboss.org maven repository refactoring is complete, bad is that the JBoss products have no maven repository, but working on it.
Maven repository is a file server with a standard layout, there are two types, release and snapshot repository.
Why use a repository
- store dependencies outside of project
- central location for build artifacts, find and re-use, single storage to manage
- manage dependencies
Configuring maven repositories
- super POM, adds central repository automatically to all builds
- add custom repositories in your project POM (you could override central by redefining the repository with id “central”)
- maven settings
– global: M2_HOME/conf/settings.xml
– user: ~/.m2/settings.xml
– profiles
Maven also uses repositories defined in the dependency poms.
Taking control :
- check effective pom : mvn help:effective-pom
- which does not show dependency repositories
- use user settings.xml
- use mirror settings for more control
Mirror settings in settings.xml
<mirror>
<id>superfast</id>
<mirrorOf>central</mirrorOf>
<name>Fast mirror of central</name>
<url>http://superfast.org/maven2</url>
</mirror>Or replace all…
<mirror>
<id>superfast</id>
<mirrorOf>*</mirrorOf>
<name>Fast mirror of central</name>
<url>http://superfast.org/maven2</url>
</mirror>Maven repository managers
- web server providing maven repositories
- real, proxy, virtual repositories
- pom validation
- products: archiva, artifactory, nexus
Rebuilding jboss.org repository
- old two servers, one for releases, one for snapshots
- problems
– deployment over SVN
– manual uploading thirdparty jars
– manual search indexing
– bad artifacts
– no staging
Goals for new repository
- sort out good from bad
- split in several parts, jboss.org, copied, bad artifacts
- improved deployment/releases
- automated validation/cleanup
Improving the repository
- single public group for all builds
- allow standard http for public group
- use repositories in POMs during development, stricter settings during QA and release
- don’t require authentication for downloads
Dependency management
Scoping
- compile
- provided: not part of final build
- runtime: provided at runtime, but not during compile time
- test: only for testing
Dependency resolution
- provided dependencies in dependent projects are not included as dependency in main project!
Shared dependencies
- parent POMs are ideal for consolidating dependencies -> dependencyManagement
- dependencyManagement : parent defines GAV, child only defines groupId and artifactId, rest is copied
Publishing shared dependencies
- Bill-of-materials POM (BOMs)
- shared dependencyManagement section in POM
- use dependencymanagement and declare pom using scope “import”
- publish coordinated dependency sets
- new platform version -> change BOM version
When things go wrong: upstream polluters
- add exclusions in your dependency for unwanted transitive dependencies
- version conflicts : maven prefers the nearest declaration
- “mvn dependency:analyze” tries to find what is declared and not used or used and not declared
Plans for maven product repository
- publish JBoss products in maven repository format
– support artifacts for product builds
– provide EXACT artifacts used in product distributions
– harness product build to populate repository
- minimize pain of switching from community version
- code ownership
Audit trail
- certification of build process and resulting product
- preserve unbroken chain of custody from source code to running software
Certified binaries
- preserve information about every step from source to binary
- secure all steps and machinery used
- build outputs signed
- restricted network access
Coordinate design
- preserve groupId and artifactId from community, changing would require dependency exclusions
- coordinate has to be different
- visual cue, add “-redhat” in version”
How : use BOM, will require maven 3 to work properly