Ram Kulkarni [Ram Kulkarni] - Java EE 8 Development with Eclipse

It is typical when you are using source control management to create separate branches for features or even for bug fixes. The idea is that the main or the master branch should always have the working code and you do development on the branches that may not be stable. When you finish a feature or fix a bug and know that the branch is stable, then you merge the code from that branch to the master branch.

To create a new branch, go to the Git Repositories view and right-click on the repository you want to branch. Then select the Switch To | New Branch... option:

Note that the Checkout new branch box should be checked. Because of this option, the new branch becomes the active branch once it is created. Any changes you commit are going to be in this branch and the master branch remains unaffected. Click Finish to create the branch.

Let's make some changes to the code, say in the main method of the GitTestApp class:

Commit the preceding changes to the new branch.

Now let's check out the master branch. Right-click on the repository in the Git Repositories view and select Switch To | master . Open the file you modified in the new branch. You will observe that the changes you made to the file are not present. As mentioned previously, any changes you do to branches are not committed to the master branch. You have to explicitly merge the changes.

To merge the changes from branch bug#1234 to the master branch, right-click on the repository in the Git Repositories view and select Merge... :

Select branch bug#1234 . This branch will be merged in the master branch. Click Merge . Git will display a summary of the merge. Click OK to complete the merge operation. Now the file in the master branch will contain the changes done in branch bug#1234 .

We have merged all the changes from branch bug#1234 to the master and we no longer need it. So, let's delete branch bug#1234 . Expand the Branches node in the Git Repositories view and right-click on the branch to be deleted (the selected branch should not be the active branch when deleting). Then select the Delete Branch menu option:

Java Enterprise Edition (JEE, which was earlier called J2EE) has been around for many years now. It is a very robust platform for developing enterprise applications. J2EE was first released in 1999, but underwent major changes with the release of version 5 in 2006. Since version 5, it has been renamed Java Enterprise Edition (JEE). Recent versions of JEE have made developing a multi-tier distributed application a lot easier. J2EE had focused on core services and had left the tasks that made application development easier to external frameworks, for example, MVC and persistent frameworks. But JEE has brought many of these frameworks into the core services. Along with the support for annotations, these services simplify application development to a large extent.

Any runtime technology is not good without good development tools. The Integrated Development Environment (IDE) plays a major part in developing applications faster, and Eclipse provides just that for JEE. Not only do you get good code editing support in Eclipse, but you also get support for build, unit testing, version control, and many other tasks important in different phases of software application development.

In this chapter, we are going to cover the following topics:

• Introduction to different technologies in JEE
• Introduction to the Eclipse development environment
• Installation and configuration of some of the frequently used software in this book, for example, JEE servers, Eclipse IDE, and MySQL Database Server

The goal of this book is to show how you can efficiently develop JEE applications using Eclipse by using many of its features during different phases of the application development. But first, here is a brief introduction to JEE and Eclipse.

Let's examine some of the files created by the template:

• src/main/webapp/WEB-INF/web.xml: A front Controller servlet is declared here, along with other configurations:

DispatcherServlet is the front Controller servlet. It is passed the path of the context (XML) file for configuring Spring DI. Recall that in the standalone Spring application, we created context.xml to configure dependency injection. The DispatcherServlet servlet is mapped to handle requests to this web application.

• src/main/webapp/WEB-INF/spring/appServlet/servlet-context.xml: Context configuration for Spring DI. Some of the notable configuration parameters in this file are as follows:

This enables annotations for configuring dependency injection at the class level:

Static files, such as CSS, JavaScript, and images, can be placed in the resources folder (src/main/webapp/resources):

This tells Spring to use the InternalResourceViewResolver class to resolve Views. Properties of this bean tell the InternalResourceViewResolver class to look for the View files in the /WEB-INF/views folder. Furthermore, Views will be JSP files, as indicated by the suffix property. Our Views will be the JSP files in the src/main/webapp/WEB-INF/views folder:

This tells Spring to scan the packt.jee.course_management package and its sub-packages to search for components (annotated by @Component).

The default template also creates one Controller and one View. The controller class is HomeController in the package that you specified in the Spring project wizard (in our example, it is packt.jee.course_management). Controller in Spring MVC is called by the dispatcher servlet. Controllers are annotated by @Controller. To map the request path to a Controller, you use the @RequestMapping annotation. Let's see the code generated by the template in the HomeController class: