Maven Repository Changes Discussion
2014-07-22
Chris J, Rob N, Skye B, Jing T, Dave V, Peter S, Mark S, Robert W, Ben L
Setup
General plan is to replace the file system based maven repo on dev-testing with something a bit more sophisticated that can also cache upstream artifacts.
Proposal 1: adopted
maven.dataone.org to replace the dev-testing.dataone.org/maven
Benefit is not tying our dependency management to a single machine name.
Cost is adding to our poms the new repository name.
Target 1.4 release
Proposal 2: adopted
- Use Maven Mangement software for the DataONE Maven repository
ProxyPass /jenkins http://localhost:8080/jenkins nocanon
ProxyPassReverse /jenkins http://localhost:8080/jenkins
ProxyRequests Off
AllowEncodedSlashes NoDecode
<Proxy http://localhost:8080/jenkins*>
Order deny,allow
Allow from all
</Proxy>
Target 1.4.* release
Proposal 3: needs more research
- Issue to solve: we can publish artifacts into prod that was built on a branch (aka beta) build.
- Software Release Lifecycle management for dependencies
- Build and install our maven components whenever they are at an acceptable software lifecycle of development or release.
- alpha-snapshots (trunk/unstable)
- beta-snapshots (branch)
- release candidates (tags)
- releases (tags)
- Need a mechanism to generate the correct artifact versions for the correct software lifecycle stage.
- maven's profile mechanism
- can create a named ID that we can associate with a lifecycle build. We can change out our version tags by profile.
- or within pom have singular release that's published to different repos.
- Problem. What if we need to change a profile to combine different states into a development build (say, beta branch depends upon released products, rather than other beta branches)
- "what (is) a Maven profile.. allowed to override(?) The short-answer to that question is that a Maven profile can override almost everything that you would have in a pom.xml."
- Other Plugins to research that will perform similar (and possibly cleaner) actions
Proposal 4: adopted
Manage all dependencies with Archiva, not just DataONE components.
why? because a dependency may be unavailable from remote repos. If the dependency is unavailable then the jenkins build process may fail and corrupt the maven repository. We have dealt with this problem in the past on hudson by wiping the maven repository nightly and rebuilding dev, but it has a tendency to slowdown any other build processes for a couple of hours each night. It is not always guaranteed to work.
Proposal 5: (review which products to publish, and establish workflow for publish to Maven Central)
publish products to Maven Central.
why?
products are more easily discoverable by developer community.
Define which artifacts to publish
Any Tagged Release of
dataone-common-java
dataone-libclient-java
Who publishes the artifacts?
What status triggers the publishing of Artifacts?
Procedural
- Copy over past DataONE artifacts from dev-testing to Jenkins-1.dataone.org
Artifact naming sequence:
foo-1.0.0-alpha-SNAPSHOT
prototyping, early development
foo-1.0.0-beta-SNAPSHOT
hardening implementation
foo-1.0.0-RC1
Perhaps this is good?
foo-1.0.0-RC2
Maybe this one?
...
foo-1.0.0
This is really the one
Prducts dependent on a SNAPSHOT - snapshot copies are always retrieved (more recent timestamp is always considered newer version)
References
- Naming convention suggestions for artifacts: http://stackoverflow.com/questions/3150003/naming-convention-for-maven-artifacts
- wtfia snapsot: http://stackoverflow.com/questions/5901378/what-exactly-is-a-maven-snapshot-and-why-do-we-need-it
- Intro to build profiles: http://maven.apache.org/guides/introduction/introduction-to-profiles.html
- Build numbe plugin: http://mojo.codehaus.org/buildnumber-maven-plugin/usage.html
- Profiles for timestamping: http://stackoverflow.com/questions/10514425/using-maven-profile-for-artifact-versioning
Example of Software Release Lifecycle management via profile in POM
Profile shows three different lifecycle states: BETA, RELEASE CANDIDATE and RELEASE
Default setting is for development (alpha)
In order to build a Beta release of the project then call maven like:
mvn -PBETA clean install
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.dataone.cn</groupId>
<artifactId>d1_cn_rest</artifactId>
<packaging>war</packaging>
<version>${this_artifact_version}</version>
<name>DataONE_Cn_Rest</name>
<url>http://dataone.org</url>
<properties>
<this_artifact_version>1.4.0-ALPHA-SNAPSHOT</this_artifact_version>
<d1_common_java_version>1.3.0-ALPHA-SNAPSHOT</d1_common_java_version>
<d1_libclient_version>1.4.0-ALPHA-SNAPSHOT</d1_libclient_version>
</properties>
<profiles>
<profile>
<id>BETA</id>
<properties>
<this_artifact_version>1.3.0-BETA</this_artifact_version>
<d1_common_java_version>1.2.1-BETA</d1_common_java_version>
<d1_libclient_version>1.3.0-BETA</d1_libclient_version>
</properties>
</profile>
<profile>
<id>RC</id>
<properties>
<this_artifact_version>1.2.2-RC</this_artifact_version>
<d1_common_java_version>1.1.1-RC1</d1_common_java_version>
<d1_libclient_version>1.2.5-RC5</d1_libclient_version>
</properties>
</profile>
<profile>
<id>RELEASE</id>
<properties>
<this_artifact_version>1.2.2</this_artifact_version>
<d1_common_java_version>1.1.1</d1_common_java_version>
<d1_libclient_version>1.2.5</d1_libclient_version>
</properties>
</profile>
</profiles>
</project>