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-

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-

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-

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

What are the best practices for Java development team?

At individual level
In Eclipse IDE use following files and share with team to maintain consistency.

PMD-rules-eclipse.xml
Eclipse-Clean-Config.xml
Eclipse-Code-Formatter.xml
Eclipse-Code-Template.xml
Eclipse-Import-Order.importorder

TestNG Test Cases
Emma plug in to check code coverage
Tie the memory and performance numbers to test cases

At team level
What happens in Hudson?
Configure following in Hudson, so that it is easy to check after each build.

Code Coverage Report
Open Tasks Report
PMD Report
Surefire Test Report

At organizational level
How to compare different projects / modules in organization?
Use SONAR and use maven plug in to push the data to Sonar server.

Code Coverage
Comments
Complexity
Lines of Code
PMD
Test Success

References:
http://java.net/projects/hudson/
http://www.sonarsource.org/
http://pmd.sourceforge.net/
http://emma.sourceforge.net/

Continuous Integration

Here are the best tools I used for continuous integration.

More information – http://en.wikipedia.org/wiki/Continuous_Integration

***** Hudson – http://hudson-ci.org/ (This is having lot of plugins. Which are easy to configure and use.)
**** Continuum – http://continuum.apache.org/ (A little bit confusing with compare to Hudson)
*** CruiseControl – http://cruisecontrol.sourceforge.net/

-o-