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 was assigned to work with ten year old legacy Java project. The code base is huge and it's my first encounter with big enterprise project.
I'm confused about the project structure, as there are dozens of something.jar called directories inside src/application.ear directory, each of these jar folders containing it's own ant build and configuration. Yet the final build will be single ear. Is the rationale for building jars from different subsystems to ship them to possibly integrated system? Is this some common pattern to name the folders by the jar names?
Is the rationale for building jars from different subsystems to ship them to possibly integrated system?
Yes,
EAR (Enterprise ARchive) is a file format used by Java EE for packaging one or more modules into a single archive so that the deployment of the various modules onto an application server happens simultaneously and coherently.
In the J2EE world, an entreprise application can be composed of web modules, ejb modules, etc.
So (and this is me guessing), the directories called something.jar can be submodules of the enterprise application o library modules required by the application (EAR)...
Is this some common pattern to name the folders by the jar names?
I don't really. I never had seen before. But I understand the purpose of such layout. The purpose is to encapsulate the files (build.xml -- ant tasks) that build some artefact called something.jar ("required by the EAR app, perhaps?"). So using this layout, a developer can easily identify which build file (build.xml) constructs what artefact. Also, using this layout, a developer can define a master build script that coordinates the order and execution of the other build scripts (EAR submodules).
So, in other words, you're watching a "pseudo" Maven framework, using ANT as implementation...
May be is time to start migrating this old application to the maven model!
I am writing a Bukkit plugin in Eclipse in which I separate different functions into different packages and export each package as its own jar file.
However, I would still like to keep these packages in the same project, rather than separating them into different Eclipse projects. These plugins each have files which must be in the root of the jar file, such as plugin.yml. I have moved each jar's files into their respective packages, but these files are put into plugin.jar\com\Preston159\plugin rather than in the root of the jar file (plugin.jar\), causing the plugin not to work.
Does Eclipse have any function to make these files automatically compress into the root of the jar file even though they are contained within the package in the source, or, is this something that I could solve by using Maven? My current solution to this problem is to move the files manually after exporting the jar, but this is becoming increasingly annoying.
EDIT:
The project builder XML I ended up using to complete this task can be found here
You would need to use a Build Tool. There are several supported by Eclipse. Ant and Maven are now built-in, but there are several build tools that run directly within Eclipse, but Eclipse can also be configured to run an external build tool as well.
Do a quick search on build.xml for examples of ANT build jobs.
Unless you're specifically required to use MAVEN for continuous integration, etc. then what you want to accomplish would be easily done with ANT.
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.
I keep server and client code in the same project of Eclipse. Libraries for both of them are included. Images for the client are also added to the build path.
Now I want to generate jars for server and client, that they include only required libraries, and server jar does not have images included.
Is there a way to do this without maven, etc?
Right-click on the project and go to Export. Select jar from the selection tree and in the next tab, remove the code/resources that you don't want included in the jar. Better still if you keep them in separate projects (even if there is no client java code, you can create a resource project).
However, what you're describing sounds a lot like a WAR file. Contrary to a jar, a WAR file is a deployable jar meant to be added to a web hosting application like Tomcat. I don't know if that's suitable for your needs, but more often than not, you want to have both server and client code together. If your project is dependent upon another project, that project will automatically create a jar that will be included in the WAR.
You can divide your sources into three source (and output) folders within the same project:
src-shared
src-server
src-client
Then create a build.xml (Ant buildfile) which creates a jar from bin-shared + bin-server and a jar from bin-shared + bin-client.
Note: One danger of keeping it in the same project is that you can accidentally use client classes from server classes, or vice versa, which will fail at runtime. To fix this, make three projects instead of three source folders.