JBoss maven repository, Paul Gier and John Casey

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

  <name>Fast mirror of central</name>

Or replace all…

  <name>Fast mirror of central</name>

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

– 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

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen