How to Access a Maven Repository » History » Revision 5
Revision 4 (Henning Blohm, 11.12.2013 14:14) → Revision 5/26 (Henning Blohm, 21.03.2014 17:01)
h1. Maven Repos Support The main idea behind this concept is to hook existing Maven repositories in as component repositories. At first this is most useful for libraries, later this may be extended to other archetypes. Maven repository suppport can be implemented in z2-base and does not require core changes. h2. Principles The main idea is that based on some root artifacts and some maven remote repository configuration, jar artifacts and dependencies will be made available as Java component in Z2 that can be referenced or included as suits best. h2. Name mapping and version resolution mappings Artefacts in Maven repos have a fully qualified name of the form <pre> <groupId>:<artifactId>:<version> </pre> where <groupId> is something like *org.acme*, <artefactId> is something like *mylibrary* and <version> is a fully structured _major.minor.micro_ style version or <pre> <groupId>:<artifactId>:<packaging>:<version> </pre> a version that has an appended "-SNAPSHOT" qualifier indicating an non-well-defined version that may receive intermediate updates. By default, When exposed via a jar artifact @<groupId>:<artifactId>:<version>@ Z2 component repository Maven artefacts will result into a Java component of be addressed by their fully qualified name <pre> <groupId>:<artifactId>/java </pre> Given that the resolution of the root artifacts as module name and dependencies lead to artifacts of the same packaging, group id, and artifact id but with different versions the higher version number will be used (but see #1695). h2. Example configuration A maven repository an archetype specific in-module component may look like this: name. E.g. a library of packaging jar, will translate to <pre> com.zfabrik.systemStates.participation=com.zfabrik.boot.main/sysrepo_up <groupId>:<artefactId>:<version>/jar com.zfabrik.component.type=com.zfabrik.mvncr mvn.priority=200 mvn.roots=\ org.springframework:spring-context:4.0.2.RELEASE,\ org.springframework:spring-aspects:4.0.2.RELEASE,\ org.springframework:spring-tx:4.0.2.RELEASE,\ org.springframework:spring-orm:4.0.2.RELEASE,\ org.springframework:spring-web:4.0.2.RELEASE,\ org.springframework.security:spring-security-core:3.2.2.RELEASE,\ org.springframework.security:spring-security-web:3.2.2.RELEASE,\ org.springframework.security:spring-security-config:3.2.2.RELEASE,\ org.springframework.security:spring-security-aspects:3.2.2.RELEASE,\ hibernate:hibernate:2.1.4,\ aopalliance:aopalliance:1.0,\ org.aspectj:aspectjweaver:1.7.4,\ org.aspectj:aspectjtools:1.6.9,\ </pre> By default, all non-optional compile scope dependencies will be resolved. The resulting Java component will have the target artifact as API library and all non-optional compile scope dependencies as public references in their mapped form. The z2 core will use lazy component class loaders to make sure that use of include libraries has virtually no runtime penalty. h2. Modifications In order to deviate from simplify management of version vectors, the default resolution and mapping, maven repository roots [[smart_props]] approach may be specified with a query string like this: utilized. <pre> org.springframework.security:spring-security-aspects:3.2.2.RELEASE?versioned=true&scope=RUNTIME </pre> *versioned:* If set Dependencies of Maven repo artefacts get mapped to @true@, Java dependencies, for the version part will not be removed from the java component name mapping and instead a versioned name is used. That is, in the case above, a java component @org.springframework.security:spring-security-aspects:3.2.2.RELEASE/java@ would be mapped. This is useful if "non-default" versions are required. *scope:* Any of RUNTIME, COMPILE, PROVIDED, SYSTEM, TEST. Conforms to the jar archetype after parsing a corresponding Maven dependency scopes. If set, non-optional dependencies of the respective scope will be traversed to resolve dependencies. POM file.