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 number of internal projects that are essentially client-side web assets that I'd like to distribute to colleagues as webjars via our repository manager. So far the development process has been:
Build an example webapp that includes the web assets I'd like to distribute and test.
Create a separate project with copies of the assets located in src/main/resources/META-INF/resources rather than src/main/webapp; set <packaging> to jar rather than war in pom.xml. Build and deploy the jar artifact to the repository manager.
Create a third project as a testbed to verify that everything works correctly when the jar file from (2) is included as a project dependency.
I'd like to combine (1) and (2) so that I can test and release from a single project. I'll need to get Maven to selectively move the distributable assets to the right locations. Seems like I'd also need a way to switch <packaging> as well. Any suggestions on how to do this or better alternatives?
Unfortunately I don't think there is a good way to deal with this when using WAR-based webapps because WAR files aren't like JAR files. If you were using a non-WAR-based web framework (Play Framework, Dropwizard, etc) then you could definitely keep JAR packaging and have both the static assets and the testing app in a single JAR.
In Eclipse Java EE perspective, how does one add a thridparty Jar to a Utility Project?
To elaborate: In a "normal" Java (Not Java EE) project, there's Referenced Libraries where you can put jars. In a Dynamic Web Project, there's Web App Libraries. In a Utility Project, there's only EAR Libraries, which don't appear relevant (well, there are Referenced Libraries that show up in the Package Explorer in Java perspective, but not in the Project Explorer in the Java EE perspective). I went ahead and added a /lib directory under my Utility Project root, and put a jar there (I forgot if I did that in the Java Package perspective, or just in the file system). I added it to Java Build Path, and everything compiles, including the Dynamic Web projects that reference the Utility Project. But when I deploy to Tomcat, I get ClassNotFoundException for the classes in the thirdparty jar.
How do I add the thirdparty jar to the Utility Project in a way that will make it get deployed as part of the web application?
I answered something similar before.
Eclipse and How it Handles JARS -- Odd Case
In essence, there's a difference between build-time and run-time JAR dependencies. For inclusion in EAR / WAR files, you have to use the "Deployment Assembly" panels.
I am not sure to understand exactly your question, but you can simply right-click on your project, in Properties you select Java Build path > Libraries, and then add your JAR in the list of third parties libraries. This will add your jar in the classpath project.
Another way is to use the (ugly) solution of creating a lib directory, put all your third parties libraries in it, and add this directory in the classpath of your project (like for the previous solution, as you can add a whole directory in Eclipse project).
The last solution is to give the responsibility of the dependencies management to a real build system, such as Maven, Ant+Ivy, Gradle...
Summary
Classes from 3rd party jar files are accessible when added to build path while running a standalone JUnit test, but "ClassNotFoundException" when accessed through plain old java objects from within a dynamic web project.
IDE used: Eclipse
Web Server: Apache 7
Details
My project required a lot of 3rd party jars, namely sqlite, eclipse jdt & jsoup. I had created this project as a standalone project and all the classes from the jars were accessible fine.
But now I have copied the entire "src" folder into a "dynamic web project". I have created a folder "jars" which contains all these 3rd party jars and ensure that all of these are added to the build path by following these steps:
Project properties --> Java Build Path --> Libraries --> Add jars --> Select all the jar files from jars folder.
These jars are accessible fine when I run a standalone JUnit test inside the web project. Note that this junit test does not require a server by any means.
But when I try to "Run on Server.." , I keep on getting ClassNotFoundException like these for all the 3rd party classes:
java.lang.ClassNotFoundException: org.sqlite.JDBC
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1672)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1517)
I'm sure this has got to do something with my lack of knowledge of how applications are deployed on the web.
The runtime classpath can be different from the build classpath. Create an explicit launch configuration. The default will start with the build classpath but you may have to manually tweak it to include those 3rd party jars.
I've run into this problem before with Eclipse and the Web Server Tools project. Check your .settings files and other files for configuring the plugins that you're using with your project. You may have to remove some filters in the Eclipse view. WST constructs its build path differently, so it may not be using the jars that you've included in your project.
I figured it out. I just had to put all the jars in the WEB-INF/lib directory. I assumed that Eclipse would do all the required settings for me when I asked it to use the mentioned jars. But I guess there are somethings that are not automated very well.
I have smallish personal project consisting of the following Eclipse workspace.
+
+-MyApp // this is just a vanilla Java Application
+-MyWebApp // this Dynamic Java Web Application (Tomcat)
+-MyCommonStuff // these are common classes
// Ex. Database access code & business classes
This is all well and good when I'm running on eclipse coz I can use Eclipse build properties to make the two apps reference the common project.
I am now thinking of how to deploy my app to a linux server and I'm wondering how to do it.
Can eclipse be used to build appropriate targets which can then reference the common stuff when running in a live environment?
Or do I have to learn how to use builders like Ant or Maven.
Thanks
You just need to add the common projects to the build path of the webapp project and to add them as web library dependency.
In the properties of your webapp project, go to Java Build Path > Projects and select the the common projects from your workspace to add them to the build path. Then, in the Java EE Module Dependencies select the projects which needs to be exposed in the WEB-INF/lib. That should be it.
You don't have to learn to use maven, but there are compelling reasons for doing so.
One of which is, maven can set up your Eclipse's build path up for you (And the next guy who has to work on your code, and the next guy...)
One simple 'mvn eclipse:eclipse' and all your build path setup is done!