Maven – Dependency Version Requirement Specification

Dependencies’ version element define version requirements, used to compute effective dependency version. Version requirements have the following syntax:

1.0: “Soft” requirement on 1.0 (just a recommendation, if it matches all other ranges for the dependency)
[1.0]: “Hard” requirement on 1.0
(,1.0]: x <= 1.0
[1.2,1.3]: 1.2 <= x <= 1.3
[1.0,2.0): 1.0 <= x = 1.5
(,1.0],[1.2,): x = 1.2; multiple sets are comma-separated
(,1.1),(1.1,): this excludes 1.1 (for example if it is known not to work in combination with this library)

Reference:
http://maven.apache.org/pom.html

Notes: This notation is good for products.
Not good for service projects. We need to have tight grip on versions, which are going into production from time to time.

-o-

Advertisements

Maven Repository – Best Practices

Problem: Many are pointing public repos. This is not good practice.

Suggested:
Setup JFrog QA and Prod repos in organization.
JFrog QA pulls files from public repos on demand basis or periodic basis.
Builds will be tested and make sure that there are no corrupted jars and all are having proper required license.

Developers can point JFrog QA repo.
When build need to happen in Junkins/Hudson…it uses JFrog Prod.
Developers need to inform admins about required files.
Admins assure integrity of required jars to push to JFrog prod.
Also they will validated required licensing issues for given jars.
This is more safest and controlled way to control final artifacts which are going into production.

References:
https://github.com/SeleniumHQ/selenium/issues/1735ac
http://stackoverflow.com/questions/20582856/maven-downloads-corrupted-jar
-o-

Gradle

Gradle is an open source build automation system that builds upon the concepts of Apache Ant and Apache Maven and introduces a Groovy-based domain-specific language (DSL) instead of the XML form used by Apache Maven for declaring the project configuration.[2] Gradle uses a directed acyclic graph (“DAG”) to determine the order in which tasks can be run.

Gradle was designed for multi-project builds which can grow to be quite large, and supports incremental builds by intelligently determining which parts of the build tree are up-to-date, so that any task dependent upon those parts will not need to be re-executed.

The initial plugins are primarily focused around Java,[3] Groovy and Scala development and deployment, but more languages and project workflows are on the roadmap.
Source: https://en.wikipedia.org/wiki/Gradle

Directed acyclic graph: https://en.wikipedia.org/wiki/Directed_acyclic_graph
Domain-specific language: https://en.wikipedia.org/wiki/Domain-specific_language

Spring Boot with Gradle: https://spring.io/guides/gs/spring-boot/

https://gradle.org/
https://docs.gradle.org/current/dsl/

Gradle Customizations:
https://www.javacodegeeks.com/2016/12/publishing-snapshots-gradles-maven-publish-plugin.html

Notes:
1. Time to move to Gradle instead of Maven for new projects. In Maven we need to write plugins. Here easy to code directly, because it is Groovy Language.
2. Advanced features
3. Support for Java/Scala/Groovy combinational projects (Didn’t checked Maven)

Possible Issues:
1. Too much customization kills over a period of time.
2. Gradle is selling tutorials and Enterprise version. We may end up with payments in case of complex issues.
3. Better not to deviate from standard Java folder structures

-o-

Jenkins is a Swiss Knife

Jenkins is an open source continuous integration tool written in Java. The project was forked from Hudson after a dispute withOracle.

http://en.wikipedia.org/wiki/Jenkins_%28software%29

Important features for large Projects

Distributed Builds:
https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds

Setting up Master / Slave:
https://wiki.jenkins-ci.org/display/JENKINS/Step+by+step+guide+to+set+up+master+and+slave+machines

Many of us think that Jenkins is only for Build. But it can do anything by triggering scripts with parameters.

Build With Parameters Plugin:
https://wiki.jenkins-ci.org/display/JENKINS/Build+With+Parameters+Plugin

– build required branch
– deploy to given server
– build for given Profile
– restart Tomcat
– take backups
– run regression tests’
– run puppet
– run liquibase changes
– no limit on what we can to with this plugin

This type of customization gives control to Engineering teams / QA teams to build and deploy on demand basis without any support from deployment team.

Reference:

http://jenkins-ci.org/

How Jenkins Builds the Netflix Global Streaming
http://www.slideshare.net/garethbowles/building-netflixstreamingwithjenkins-juc

Self service build and deployment at Netflix (Agile 2013)
http://www.slideshare.net/garethbowles/self-servicebuilddeploymentagile2013

Conclusion: Jenkins is good free knife. After utilizing all its plugins to their maximum potential, we can see that Jenkins is a Swiss Knife.

jenkins_logo

Other tools licenses are costly and Jenkins will live long with open source contributions.

Continuous Integration (CI)

Bamboo
Atlassian’s Product and comes with easy integration with Atlassian’s products.
Bamboo
This is costly for open source / community projects.
————————————————–

Junkins (Hudson): MIT License and came with many useful plugins.
Jenkins
Nice Plugins
https://wiki.jenkins-ci.org/display/JENKINS/Plugins

I liked this plug in
https://wiki.jenkins-ci.org/display/JENKINS/Buildcoin+Plugin

From my experience Junkins is best.
————————————————–
List of Continuous Integration Software
http://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software

-o-

Maven Vs Gradle

Gradle is another Build System similar to Maven.

I didn’t like Gradle, because

1. Proprietary software build to get service agreements and make money.
2. Training is very costly.
3. Pushing away from structured development to unconventional development.

I always prefer Apache projects.

http://www.gradleware.com/services
Maven Vs Gradle
http://www.gradleware.com/resources/tech/java/maven
http://www.gradle.org/license

I may change my opinion down the line.

-o-

Cloud deployment

Deploying applications in more than one server is painful.
We need to define deployment strategy, Rollback strategy along with verification and validation process.
For each environment properties files / paths are different.
Many times Release Managers / Deployment Engineers solve this through shell/PERL Scripting and manual process with the help of runbooks.

These tools can help to reduce this manual work.

Salt – http://saltstack.com/ (*****)
Salt – http://docs.saltstack.com/topics/
Puppet – https://puppetlabs.com/
DeployIt – http://www.xebialabs.com/tour