Monday, August 20, 2018

MAVEN: An intro to the master of project build


What is Maven?

Maven is a build tool for Java software projects. You can build projects using other languages too, but Maven is used more for Java projects, as it is developed in Java. 

As per the Philosophy of Maven, and it's official site it is more than just a build tool. 

What is a Build tool?

A build tool is a tool that automates everything related to building the software project. Building a software project typically includes one or more of these activities:
  • Generating source code (if auto-generated code is used in the project).
  • Generating documentation from the source code.
  • Compiling source code.
  • Packaging compiled code into JAR files or ZIP files.
  • Installing the packaged code on a server, in a repository or somewhere else.
Maven Build Life Cycles, Phases and Goals

When Maven builds a software project it follows a build life cycle. The build life cycle is divided into build phases, and the build phases are divided into build goals.

Build Life Cycles

Maven has 3 built-in build life cycles. These are:
  • default
  • clean 
  • site
Each of these build life cycles are executed independently of each other. You can get Maven to execute more than one build life cycle, but they will be executed in sequence, separately from each other.

The default life cycle handles everything related to compiling and packaging your project.

The clean life cycle handles everything related to removing temporary files from the output directory, including generated source files, compiled classes, previous JAR files etc. 

The site life cycle handles everything related to generating documentation for your project. In fact, site can generate a complete website with documentation for your project.


Build Phases

Each build life cycle is divided into a sequence of build phases, and the build phases are again subdivided into goals. Thus, the total build process is a sequence of build life cycle(s), build phases and goals.
You can execute either a whole build life cycle like clean or site, a build phase like install which is part of the default build life cycle, or a build goal like dependency:copy-dependencies. Note: You cannot execute the default life cycle directly. You have to specify a build phase or goal inside the default life cycle.
When you execute a build phase, all build phases before that build phase in this standard phase sequence are executed. Thus, executing the install build phase really means executing all build phases before the install phase, and then executes the install phase after that.

Build Goals

Build goals are the finest steps in the Maven build process. A goal can be bound to one or more build phases or to none at all. If a goal is not bound to any build phase, you can only execute it by passing the goals name to the mvn command. If a goal is bound to multiple build phases, that goal will get executed during each of the build phases it is bound to.

The following lists all build phases of the defaultclean and site lifecycles, which are executed in the order given up to the point of the one specified.

Clean Lifecycle
pre-clean
execute processes needed prior to the actual project cleaning
clean
remove all files generated by the previous build
post-clean
execute processes needed to finalize the project cleaning

Default Lifecycle
validate
validate the project is correct and all necessary information is available.
initialize
initialize build state, e.g. set properties or create directories.
generate-sources
generate any source code for inclusion in compilation.
process-sources
process the source code, for example to filter any values.
generate-resources
generate resources for inclusion in the package.
process-resources
copy and process the resources into the destination directory, ready for packaging.
compile
compile the source code of the project.
process-classes
post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.
generate-test-sources
generate any test source code for inclusion in compilation.
process-test-sources
process the test source code, for example to filter any values.
generate-test-resources
create resources for testing.
process-test-resources
copy and process the resources into the test destination directory.
test-compile
compile the test source code into the test destination directory
process-test-classes
post-process the generated files from test compilation, for example to do bytecode enhancement on Java classes. For Maven 2.0.5 and above.
test
run tests using a suitable unit testing framework. These tests should not require   the code be packaged or deployed.
prepare-package
perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)
package
take the compiled code and package it in its distributable format, such as a JAR.
pre-integration-test
perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
integration-test
process and deploy the package if necessary into an environment where integration tests can be run.
post-integration-test
perform actions required after integration tests have been executed. This may including cleaning up the environment.
verify
run any checks to verify the package is valid and meets quality criteria.
install
install the package into the local repository, for use as a dependency in other projects locally.
deploy
done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

Site Lifecycle
pre-site
execute processes needed prior to the actual project site generation
site
generate the project's site documentation
post-site
execute processes needed to finalize the site generation, and to prepare for site deployment
site-deploy
deploy the generated site documentation to the specified web server

 The full Maven lifecycle is defined by the components.xml file in the maven-core module, with   associated documentation for reference.
In Maven 2.x, default lifecycle bindings were included in components.xml, but in Maven 3.x, they are defined in a separate default-bindings.xml descriptor.


Core of Maven - the POM xml

The core of Maven is the concept of POM files (Project Object Model). It is an xml file located in root directory of the project, which is hierarchical representation of project resources like source code, test code, dependencies. The execution steps of Maven is as follows:
> Reads POM.xml
> Downloads dependencies into local repository
> Executes life cycles, build phases and/or goals
> Executes plugins

POM describes what to build. Maven build phases describes how to build. 
Profiles

A new feature of the POM 4.0 is the ability of a project to change settings depending on the environment where it is being built. A profile element contains both an optional activation (a profile trigger) and the set of changes to be made to the POM if that profile has been activated. For example, a project built for a test environment may point to a different database than that of the final deployment. Or dependencies may be pulled from different repositories based upon the JDK version used.

Creating the POM File
Once you have created the project root directory, create a file called pom.xml inside the directory.
Inside the pom.xml file you put the following XML:
<project xmlns="http://maven.apache.org/POM/4.0.0"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                     http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>
  
<groupId>blogger</groupId>
   <artifactId>hello-world</artifactId>
   <version>1.0.0</version>
</project>

This is a minimal pom.xml file.
The groupId identifies your organization.
The artifactId identifies the project. More specifically, it identifies the artifact built from the project, like for instance a JAR file.
The version identifies the version of the artifact which the POM file builds. When you evolve the project and you are ready to release, remember to update the version number.
Other projects that need to use your artifact will refer to it using the groupId, artifactId and version, so make sure to set these to some sensible values.
Testing the POM File

When you have created the pom.xml file inside the project root directory it is a good idea to just test that Maven works, and that Maven understands the pom.xml file.
To test the pom.xml file, navigate to the project root directory, then open command window there, then execute this command:
  
    mvn clean

The mvn clean command will clean the project directory for any previous temporary build files. Since the project is all new, there will be no previous build files to delete. The command will thus succeed.
You will see that Maven writes what project it has found. It will output that to the command prompt. This is a sign that Maven understands your POM. Here is an example of what Maven could output:
D:\projects\my-first-maven-project>mvn clean
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building hello-world 1.0.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ hello-world ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.873 s
[INFO] Finished at: 2018-08-19T14:57:00+05:30
[INFO] Final Memory: 4M/15M
[INFO] ------------------------------------------------------------------------

Maven Command Structure

A Maven command consists of two elements:
  • mvn
  • One or more build life cycles, build phases or build goals
Here is a Maven command example:
 
  mvn clean install

This maven command executes the clean build life cycle and the install build phase in the default build life cycle.


Maven Archetypes

Maven archetypes are project templates which can be generated for your project by Maven. In other words, when you are starting a new project you can generate a template for that project with Maven. In Maven a template is called an archetype. Each Maven archetype thus corresponds to a project template that Maven can generate.

Available Maven Archetypes

Maven contains a lot of archetypes, so this Maven archetype tutorial will just show you some of the most commonly used archetypes. To see a full list of Maven archetypes, simply run this command:
    mvn archetype:generate

This command actually intends to generate a Maven archetype for you, but since you have not specified in the command which archetype to build, Maven will output all its available archetypes to the command prompt. At the end Maven will ask you which Maven archetype to generate. If you know the number of the archetype to generate, you can type in the number in the command prompt and press enter.
The list contains more than 1.300 Maven archetypes, so it is not really that easy to find the archetype you need. Too look at the list of available Maven archetypes, you can pipe the output into a file, and open that file in e.g. Notepad++ or so. You pipe the available Maven archetypes into a file using this Maven command:

mvn archetype:generate > archetypes.txt

Named Archetypes
Maven contains a set of named archetypes which you can create. Eg:-

Eclipse
There is a Maven archetype which can generate a new Java project including files for the Eclipse IDE. You can generate that archetype using this Maven command:

mvn eclipse:eclipse

Before you can generate this Maven archetype though, you need to have a POM file in the project root directory into which you want to generate the archetype.

More information on Maven follows in the next post.........


Sunday, September 20, 2015

Overcome duplicate form submission in Struts

There are three parts of any struts code which we use for validation of user fields:
1) Form Bean
2) Form Action
3) Submit Action

With appropriate use of tokens in these classes we can avoid duplicate form submission, a vector for Cross Site Request Forgery (CSRF of XSRF).

Where to use:
1) Inside Form Bean:
   Right after instantiating Action Error inside Validate() method write below lines:

   String token =request.getParameter("org.apache.struts.taglib.html.TOKEN");
    if(isToken!==null)
        {
              //write your validation code here
         }
2) Inside Form Action:
    Right after instantiating FormBean, put below line:
         saveToken(request);

3) Now, the turn of Submit Action:
     isTokenValid(request)
        {
           //Write all your valitaion code here
        }
    Close the loop and put a suitable redirect in case validation fails.

4) The knotty stuffs needed now
 > Make entry for redirection in struts.config file in case the validation fails.
 > Create a jsp with error message and make entry of this jsp in tiles.xml.
    One simple example of error.jsp:
    Unable to access the page you are looking.