Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I am a beginner in learning Java. kindly give a detailed explain or add a video link of the same.
Dynamic web projects
Dynamic web projects can contain dynamic Java EE resources such as servlets, JSP files, filters, and associated metadata, in addition to static resources such as images and HTML files.
Java EE conventions may represent extra overhead if you only want to create a static, content-based Web application, which contains no dynamic files, such as JSP files or servlets. In this case, when you need only the most basic Web project, you might want to use the static Web project type (see Static Web projects). Note that static Web projects can be converted to dynamic Web projects by selecting Convert to a Dynamic Web Project, from the Project menu.
Dynamic Web projects are mostly embedded in Enterprise Application projects. The wizard that you use to create a dynamic Web project will also create an Enterprise Application (EAR) project if it does not already exist. The wizard will also update the application.xml deployment descriptor of the specified Enterprise Application project to define the Web project as a module element. If you are importing a WAR file rather than creating a dynamic Web project new, the WAR Import wizard requires that you specify a Web project, which already requires an EAR project.
The Java EE model, and more specifically, the Sun Microsystems Java™ Servlet 2.3 Specification, defines a Web application directory structure that specifies the location of Web content files, class files, class paths, deployment descriptors, and supporting metadata. The Web project hierarchy mirrors that of the Web application created from a project. In the workbench, you can use the New Web Project wizard to create a new Web project.
The main project folder contains all development objects related to a Web application. The Web content folder contains the elements of the project necessary to create a Web application. This folder structure maps to the Web application archive (WAR) structure defined by Sun Microsystems.. The following default elements are located in the Web project folder hierarchy:
Web Deployment Descriptor
The standard Web application deployment descriptor (the web.xml file).
JavaSource
Contains the project's Java source code for classes, beans, and servlets. When these resources are added to a Web project, they are automatically compiled and the generated files are added to the WEB-INF/classes directory. The contents of the source directory are not packaged in WAR files unless an option is specified when a WAR file is created.
imported_classes folder
This folder may be created during a WAR import, and contains class files that do not have accompanying source. The imported_classes folder is a Java classes folder; Java classes folders can also be created using the Web project Java Build Path properties page.
WebContent folder
The mandatory location of all Web resources, including HTML, JSP, graphic files, and so on. If the files are not placed in this directory (or in a subdirectory structure under this directory), the files will not be available when the application is executed on a server. The Web content folder represents the contents of the WAR file that will be deployed to the server. Any files not under the Web content folder are considered development-time resources (for example, .java files, .sql files, and .mif files), and are not deployed when the project is unit tested or published.
META-INF
This directory contains the MANIFEST.MF file, which is used to map class paths for dependent JAR files that exist in other projects in the same Enterprise Application project. An entry in this file will update the run-time project class path and Java build settings to include the referenced JAR files.
theme
The suggested directory for cascading style sheets and other style-related objects.
WEB-INF
Based on the Sun Microsystems Java Servlet 2.3 Specification, this directory contains the supporting Web resources for a Web application, including the web.xml file and the classes and lib directories.
/classes
This directory is for servlets, utility classes, and the Java compiler output directory. The classes in this directory are used by the application class loader to load the classes.
Folders in this directory will map package and class names, as in: /WEB-INF/classes/com/mycorp/servlets/MyServlet.class.
Do not place any .class files directly into this directory. The .class files are placed in this directory automatically when the Java compiler compiles Java source files that are in the Java Resources directory. Any files placed directly in this directory will be deleted by the Java compiler when it runs.
/lib
The supporting JAR files that your Web application references. Any classes in .jar files placed in this directory will be available for your Web application
Libraries
The supporting JAR files that your Web application references. This folder mirrors the content of the lib folder. In addition, Web Library Projects, which are "virtual" JAR files that do not physically reside in the Web project, but are associated with Java projects elsewhere in your workspace, are included in this folder. They are packaged with your project when you export the application's WAR file.
Note: A library entry on the Java build path will remain there unless the actual JAR file is deleted from the WEB-INF/lib folder. If you remove a library path entry but not the JAR file, the library entry will be re-added to the path automatically.
Gradle Projects :
Gradle is a general purpose build management system. Gradle projects can be something which should be built or something that should be done.
Each project consists of tasks. A task represents a piece of work which a build performs, e.g., compile the source code or generate the Javadoc.
These build files are based on a Domain Specific Language (DSL). In this file you can use a combination of declarative and imperative statements. You can also write Groovy or Kotlin code, whenever you need it. Tasks can also be created and extended dynamically at runtime.
The following listing represents a very simple build file.
task hello {
doLast {
println 'Hello Gradle'
}
}
To execute the hello task in this build file, type gradle hello on the command line in the directory of the build file. If the Gradle output should be suppressed, use the -q (quiet) parameter.
gradle hello
# alternative add the -q flag
gradle -q hello
Whats we get extra with gradle is -
Declarative builds and convention over configuration
Gradle uses a Domain Specific Language (DSL) based on Groovy to declare builds. The DSL provides a flexible language that can be extended by us. As the DSL is based on Groovy, we can write Groovy code to describe a build and use the power and expressiveness of the Groovy language.
Gradle is designed to be a build language and not a rigid framework. The Gradle core itself is written in Java and Groovy. To extend Gradle, we can use Java and Groovy to write our custom code. We can even write our custom code in Scala if we want to.
These projects have sensible convention-over-configuration settings that we probably already use ourselves. However, we have the flexibility to change these configuration settings if required for our projects.
Gradle supports -
Ant Tasks and Maven repositories
Incremental builds
With Gradle, we have incremental builds. This means the tasks in a build are only executed if necessary. For example, a task to compile source code will first check whether the sources have changed since the last execution of the task. If the sources have changed, the task is executed; but if the sources haven't changed, the execution of the task is skipped and the task is marked as being up to date.
Multi-project builds
Gradle has great support for multi-project builds. A project can simply be dependent on other projects or be a dependency of other projects. We can define a graph of dependencies among projects, and Gradle can resolve these dependencies for us. We have the flexibility to define our project layout as we want.
Gradle has support for partial builds. This means that Gradle will figure out whether a project, which our project depends on, needs to be rebuild or not. If the project needs rebuilding, Gradle will do this before building our own project.
Gradle Wrapper
The Gradle Wrapper allows us to execute Gradle builds even if Gradle is not installed on a computer. This is a great way to distribute source code and provide the build system with it so that the source code can be built.
Also in an enterprise environment, we can have a zero-administration way for client computers to build the software. We can use the wrapper to enforce a certain Gradle version to be used so that the whole team is using the same version. We can also update the Gradle version for the wrapper, and the whole team will use the newer version as the wrapper code is checked in to version control.
Advantage of Gradle over IDE specific Dynamic web project
Project Modularization
Project conventions suggest (or better, force) the developer to modularize the project. Instead of a monolithic project you are often forced to divide your project in smaller sub components, which make it easier debug and manage the overall project structure
Dependency Management and Project Lifecycle
Overall, with a good SCM configuration and an internal repository, the dependency management is quite easy, and you are again forced to think in terms of Project Lifecycle - component versions, release management and so on. A little more complex than the ant something, but again, an improvement in quality of the project.
Portability
Each IDE has its own project structure. While other IDEs may have the option to import Eclipse settings it may not be without problems.
Also Eclipse settings are very local. Importing an Eclipse project from another person will easily require reconfiguration (JDK path/version, etc).
In Gradle the local machine specifics are decoupled from projects, allowing people to share the same config file (pom.xml), regardless of which machine or IDE they use.
It’s easier to integrate with automatic integration tools. Headless compilation with Eclipse is rarely used and not super well documented.
Gradle handles and downloads dependencies automatically via ivy or maven plugins. It’s often problematic and painful, but Eclipse doesn’t do that at all. Manually downloading the libs, shared folders or USB shuffling is a hassle and dangerous.\
Dynamic web projects can contain dynamic Java EE resources such as servlets, JSP files, filters, and associated metadata, in addition to static resources such as images and HTML files. Static web projects only contains static resources. When you create Web projects, you can include cascading style sheets and JSP tag libraries (for dynamic Web projects), so that you can begin development with a richer set of project resources.
Gradle uses a convention-over-configuration approach to building JVM-based projects that borrows several conventions from Apache Maven. In particular, it uses the same default directory structure for source files and resources, and it works with Maven-compatible repositories.
I have a project where there are hundreds of jar files, which mostly are for different modules and some are utilities used by many modules. I use ANT to build the project. I am looking for a way where if I made code change in two modules, ANT can identify and create only two jar files for me so that I can create kind of a patch and drop two jars to the application. ANT is loading source for Microsoft Team foundation server.
I try to find the way to organize a GAE with several projects within Eclipse using the Google plugin for GAE:
The Web App project (a WebApp project) containing the GAE web application.
A Java project with data access
A Java project with utility classes
My problem here is how to link things together. I want to add the two Java projects in both build and execution paths. Since a Web App project follows the JavaEE structure, only what is specified in the WEB-INF/lib directory is taken into account.
I would like to find out how to simulate a Jar file in this directory based on a Java project present in the Eclipse workspace based on what the Google Eclipse plugin for GAE provides.
I saw something that seems to be related in the WebApp project properties Google > Web Application, section "Suppress warnings about these build path entries being outside of WEB-INF/lib".
For the GAE web application to run then you'll need the classes or a jar from the projects you want to include in the WEB-INF/classes or WEB-INF/lib folders respectively.
One way would be to build your data and utility projects and put the resulting jars in the WEB-INF/lib folder. You can then then reference those jars as libraries from your web app and all should be fine. Of course that's a bit tiresome to do manually, so you should probably check out some dependency management tools. From personal experience Ivy and IvyDE were easy to get into and should cover your needs although Maven and others have their strengths.
Another way that is a easier (but less structured) is to used linked source folders in your build path (to the source folders for your data and utility projects). In such way Eclipse will build those sub projects to WEB-INF/classes and build and execution should work similarly.
Environment
IDE: Netbeans 6.9
App Server: Glassfish 3
Frameworks: Spring, Hibernate, Struts 2
Problem
I have 2 web applications. I want to share resources between them both - i.e. authentication form jsp and other assets (js - yui,jquery/images/css). I will be adding more web applications that will also require access to these common components.
As a last resort I will create another web project with just the common assets - including them via http://common.mydomain.
How has anyone else achieved this? Can I create a web resource jar/war and include this in both applications?
I am experimenting so will update question with any progress.
Many thanks.
Place these 'common' components in a separate module (or in several separate modules) and make a dependency to this module from other parts of your app. (I'm not sure how is it called in NetBeans, in IntelliJ IDEA it's called module, in Eclipse - it's a separate project in the same workspace).
In eclipse you must create an utility project and an ear project containing the utility project and your current web applications. You can then move common code to the utility project, and deploy the ear to glassfish.
Common resources must be located through the classpath. This is rather easy with JSF 2
Netbeans has a feature to do this. Create a new project just for your shared components. List the project as a dependency of the projects that need it and make sure both projects are open in the IDE during the build process.
The IDE agnostic way(which I'm using in my own projects.)
would be to:
use maven to manage your projects
build your shared components into their own .jar
setup a local repository server(nexus, artifactory) server to host the shared .jar
(if you're the only dev, you might be able to get around this with mvn install)
list your new jar as a dependency on the projects(wars) that need it.
I have a J2EE application that needs to be distributed to customers, who will have application servers of their own choice. What is the recommended way of writing a build script that would compile the J2EE application sources (at customer sites) so that they will eventually be able to deploy the application on their servers ?
Moreover, what JARs should one actually use during the compilation process ? Since this is meant to an application server agnostic script, is it recommended to use the JARs (say servlet.jar, jms.jar, ejb.jar etc.) from the application server, rather than having my customers download these JARs from a particular repository ? Is there any such repository that is recommended for such JARs (JARs of J2EE APIs) ?
PS: The EAR file cannot be built locally and shipped to customers, since additional development will be done at each installation to integrate with other systems, perform customizations on the application etc.
Build the application locally, and distribute the WAR/EAR files to the customer.
Edit:
The situation you describe is basically that you need to provide a code base for further development by the customer. In that case I would suggest that you look into creating maven modules of your work which are pushed to a private repository accessible by the customer. You then let them know that they need to depend on module X version Y in their pom.xml, and module X then pulls in all the libraries needed in the correct versions.
Note that if they don't use Maven, they might use Ant Ivy for the dependency resolving.
Some generic J2EE API jars can be found at Sun's site, however you might have to dig a lot to find them.
I would just use any JAR you have handy, bundle it with the source, but away from /WEB-INF/lib
Basically, don't include the container jars (servlet.jar, jms.jar, ejb.jar etc.) in your EAR or WAR file.
If you are just talking about servlet.jar, the web container provides that - you shouldn't include it in your war file.
If you are creating an EAR file, they you must be using an enterprise container and it will have a JMS.jar and EJB.jar.
JMS on Tomcat would be a little trickier - you'd need people to install something like activemq on their servers.