[Java] Maven Archetype and pom.xml


1 - Project Template

Archetype are project templates that can be generated for use. To begin, run:

mvn archetype:generate


Then, the cmd will prompt you for:
  • Archetype
    • project templates - eg. web applications, JavaEE projects, Hiberate, Spring
  • Group Id
    • Uniquely identifies your project across all projects
    • Eg. org.apache.maven or org.apache.maven.reporting
  • Artifact Id
    • Name your jar (or output)
  • Version
    • Usually looks like 1.0 or 1.1.1
    • SNAPSHOT are nightly builds; meaning not released/in-development
    • RELEASE means released.
    • Avoid using dates
  • Packaging
    • The project's packaging; in other words, the output  file
    • By default, it will be jar (if none specified)
    • Valid values: pom, maven-plugin, ejb, ear, rar, war, jar
Once done, it will generate a seed maven project.

2 - pom.xml (Basic)

Basic Structure of pom.xml is:
  • maven coordinates
    • defining the maven project
  • metadata
  • build information
  • resources and dependencies

2.1 - Dependencies

Most project depend on others to build and run correctly. Dependencies is the list of libraries that you rely on.

You can manually enter the dependencies or enter the following the cmd:
mvn install:install-file -Dfile=non-maven-proj.jar -DgroupId=some.group -DartifactId=non-maven-proj -Dversion=1 -Dpackaging=jar

2.1.1 - Other Dependency Attributes

  • type
    • corresponds to the chosen dependency type.
    • By default: jar
    • (Not that commonly used)
  • scope
    • refers to the role of the task for this dependency:
      • compile - default scope. Compile dependencies available in all classpaths and propagate to dependent projects.
      • provided - similar to compile, but indicates you expect the JDK or container to provide it at runtime. It is only available in the runtime and test classpaths, but not the compile classpath.
      • runtime - indicates dependency is not required for compilation, but is for execution (or compile classpath)
      • test - indicates dependency is not required for normal use of application; only needed for test compilation.
      • system - similar to provided, expect you have to provide the jar which contains it. 
  • systemPath
    • used only if scope is system. Otherwise, the build will fail if this element is set. 
    • Path must be absolute; thus, recommended to use some machine-specific path, such as ${java.home}/lib
  • optional
    • when this project itself is a dependency.
    • For example: Assume we have a project A that depends upon project B. But project A might only use project B for certain modules; not all. Now, assume project X adds project A as a dependency. If project X does not use the module in project A that uses project B, then there is no need for project X to install project B.
      • If => represents required dependency, and --> represents optional.
      • Although A => B, X=>A--> is possible.

3 - Maven Build


Maven has clearly defined build lifecycle. Three build-in lifecycles are: default, clean and site.

3.1 - Build Lifecycle


3.1.1 - Build Lifecycles are made up of Phases


Each build lifecycle is defined by a different list of build phases. For example, the default lifecycle comparises of the following phases:
  • validate - validate project is correct and all necessary information is available
  • compile - compile source code of project
  • test - test compiled source code using suitable unit testing framework
  • package - take compiled code and package it in its distributable format, such as jar
  • verify - run any checks on results of integration tests to ensure quality criteria are met
  • install - install package into local repository, for use as dependency in other projects locally
  • deploy - done in the build environment, copies the final package to the remote repository for sharing with other developers and projects.

3.1.2 - Build Phases are made up of Plugin Goals


The build phase is responsible for a specific step in the build lifecycle, but the way to achieve it may vary - this is where plugin goals come in.

A plugin goal represents a specific task. 
A goal not bound to any build phase can be executed outside the build lifecycle by direct invocation.

3.2 - Some CMD examples

mvn clean dependency:copy-dependencies package
The cmd above will execute in the order of clean -> copy-dependency -> package
dependency:copy-dependencies is a goal (of a plugin)


It has a standard build structure.

mvn build
mvn package


Resources

https://maven.apache.org/pom.html
https://www.youtube.com/watch?v=AI8Kjag1vGk
https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html (need to finish this)

Comments

Post a Comment

Popular posts from this blog

[Redis] Redis Cluster vs Redis Sentinel

1) In-Depth Guides to Redis Cluster and Sentinel For more in-depth explanation for Redis Cluster or Redis Sentinel, please read my other posts: Sentinel:  https://notafraidofwong.blogspot.com/2019/05/redis-redis-sentinel.html Cluster:  https://notafraidofwong.blogspot.com/2019/05/redis-redis-cluster.html 2) Deciding between Redis Sentinel and Redis Cluster Similarities : Both solutions provide high availability for your system. 2.1) Redis Cluster 2.1.1) Pros Shards data across multiple nodes Has replication support Has built-in failover of master 2.1.2) Cons Not every library supports it May not be as robust (yet) as Standalone Redis or Sentinel Setup and maintenance is more complicated 2.2) Redis Sentinel 2.2.1) Pros Automatically selects new master in case of failure Easy to setup, (seems) easy to maintain 2.2.2) Cons No data sharding; master might be overutilized. Another distributed system to maintain. 3) So how do I decide? In
Read more

[Unit Testing] Test Doubles (Stubs, Mocks....etc)

Image
In unit testing, isolation is key. The goal of unit testing is to test individual components, and not an entire system . The class/object/function you are testing is System Under Test (SUT) , and the other components of the system are Collaborators or Dependencies. Test Double  is a generic term for any kind of 'pretend' object used in place of a real object for testing purposes.  There are several types of Testing Doubles. We will start with: Fake Stub Mock Command Queries Mocks vs Stubs And then: Dummy Spies Spies vs Mocks I) Basic Testing Doubles a) Fake Fake are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code. Note that Fake is a generic term - that can point to anything; usually mock and stubs. An example of this is an in-memory implementation of a database. This fake implementation will not access the actual database, but will u
Read more

[Node.js] Pending HTTP requests lead to unresponsive nodeJS

This is a recap conclusion to the potential problems of a NodeJS program I worked on previously. The program simulates thousands of clients navigating a website by sending thousands of http requests to a given API . The idea is to load test a particular API to make sure they can handle high traffic. Because we are simulating clients, it's important to keep track of the state of the simulated client as well. The problem with this program is it is buggy and becomes unresponsive from time to time (the only solution is to restart it). The problem was fixed by re-writing the entire program in Java, but it was regretful that I never had enough time to find the exact reason the nodeJS version of it failed. The following are potential causes I suspect: 1. Exceptions The NodeJS program was not written very neatly and stacked callbacks on top of callbacks on top of callbacks. This made it very difficult to keep track of exceptions and unexpected http responses are prone to happen. So
Read more