Forgive me for a novice question, but what is the difference between the dist and deploy folders? It seems like the same thing - both contains the .jar of the files. However, when you clean and build the project, it looks like only the dist folder is updated. How does the deploy folder get updated?
Thanks.
I will assume that you are using a directory layout similar to what Netbeans IDE creates by default.
dist is the folder where your generated archives are stored (so it gets updated through clean and build).
build folder contains compiled classes and resources, but not the compressed archives.
Maven, by default, places the content of both into a target folder.
A deploy folder is the place where you put your generated artifacts (either archives or directory trees with the same layout as archives, a.k.a. exploded archives) so that you Application Server can serve it.
In development environments it is not unusual to configure the server to scan the dist folders for generated artifacts and redeploy them. So, in that sense, deploy and dist folders can be the same.
You can even have "in place" deployment scenarios. This works by compiling your classes direct to WEB-INF/classes folder inside webapp (with something like Maven war:inplace goal). If you set your server to scan changes in this folder, you can edit resources such as jps in place and have it immediately reflected into your running application (a.k.a. exploded artifact hot deployment).
Of course that you can accomplish something similar by instructing your IDE to copy resources and compiled classes to a exploded archive structure and configuring your server to scan it. Netbeans tends to use build/web for that purpose.
Also sometimes incremental redeployment is not possible and frequently full redeploys are not desirable (some applications may take several minutes to redeploy). That is why you can use separate folders / deploy your artifacts as jars / wars / ears, etc.
Compiling, packaging and deploying are very different phases / concepts of a Build lifecycle, which may or may not happen together.
I hope this is enough info to get you going.
Cheers,
Typically a project is responsible for creating one artifact, when that artifact gets built it is put in a directory called target or dist. When your project is responsible for creating a web application, you need a place to layout the files in your project to run under your servlet container or app server, and that place is the deploy folder. So the dist directory would typically have a single artifact like a war, ear or jar, while the deploy folder would have the contents exploded in a directory structure where the app server can use them. How the deploy folder contents get updated depends on your build process or IDE integration.
Related
I am currently working on an EAR application which has a WEB project and EJB project in it.
To work on eclipse with local set up i do so many build path setups and all.
All these buildpaths show up in .classpath of the project.
Now when i export the EAR and deploy on Server everything works on server.
My doubt is how does server know about my local system paths which are present in .classpath of my project.
Does it mean .classpath has no significance at runtime?
Please explain.
.classpath file is eclipse specific, it will not be bundled with the EAR. Eclipse uses it to set the classpath for the project.
An EAR has a well defined structure and Servlet container understands that structure, using it's knowledge it prods around in the EAR file and extracts classes to load in the runtime.
Obviously server doesn't have any knowledge of your local environment. An EAR (or WAR or JAR) file is a simple archive file (with some specification or the file order and all). You can unzip it using any utility (something like 7zip). Check the structure of the packed EAR, that will give you a better understanding of what goes to your server.
Question
For Java web applications, if you put classes where the web server expects them on your development machine, it can save you the step of packaging and redeploying your web-app every time you compile. It also simplifies things to have the development and deployment directory structure the same. Tomcat's Standard Directory Layout is:
WEB-INF/
WEB-INF/classes
WEB-INF/lib
But SBT wants to put all classes in:
target/scala-2.10/classes
How do I tell sbt to put classes in WEB-INF/classes instead?
Background
So far, I've been using SBT just for unit tests and I run it from WEB-INF instead of my project's root directory and don't worry about where it throws the classes because tests don't need to be deployed. I guess I could wrap SBT in a batch file that cd's to WEB-INF, then cd's back when done, but that seems a little kludgey.
How do people work around this issue? I could delete WEB-INF/classes then copy target/scala-2.10/classes to it after each build, but that might eliminate some of the benefits of incremental/minimal compilation that SBT offers.
Extra Credit...
I'm not sure if this is part of a new question, but it falls under "using SBT to build a Java web app" so I'll include it: Tools like log4j, Struts, proxool, and Hibernate all seem to expect files (and sub-directories recursively) to be copied from src/main/resources to classes on each build, and I could copy them explicitly the way I do with the Ant build now. But if SBT had a web-app-defaults, maven-defaults, or java-defaults template or something, that would be helpful to know about.
I think it should be
target := base / "WEB-INF"
or
classDirectory := base / "WEB-INF" / "classes"
I have a project set up like this:
/parent
/core
/src/main/
/resources/META-INF/
web-fragment.xml
/resources/jsp/
fragment.jsp
/java/
FragmentTest.java
/web
/src/main/
/webapp/
/WEB-INF/web.xml
/jsps/
parent.jsp
/java/
ParentTest.java
the 'core' compiles to a .jar within the .war.
However, when deploying this to Tomcat, with debug enabled, I can edit parent.jsp and it will hot deploy, however if I update fragment.jsp then it will not, and I have to rebuild/redeploy/etc.
However, any changes to the .java in either project will hot-deploy successfully.
Is anyone aware of any configurations, etc. that may be missing to get web-fragment JSPs to hot deploy?
Thanks!
I have the same situation. I have test-web (your parent) and test-web-fragment (your core). I resolved them in the following way:
In the /test-web -> Properties -> Deployment Assembly I added the Fileset rule that points to /test-web-fragment/src/main/resources/META-INF/resources (See the screenshots below).
When I change something in a page from fragment, the eclipse builder copies it to /test-web/src/main/webapp. After that I do a right click to test-web in app server and click Full Publish and I have to the server my changes. This trick I use in the development mode. When I make the build for production I use maven, without this rule.
Your project structure confuses me a bit. We always place JSPs in /src/main/webapp and sub folders therein. I can very well imagine this to be the source of your problem.
You will be able to hot deploy both JSPs and Java files if you do the following:
Separate your web fragment project into two different projects and reference them from your main Web applications:
One containing all your Java source files (this project has to be a Web Fragment). This will be packed as a JAR file and you will be able to hot deploy Java files as you're currently doing
Another project, a Dynamic Web Project, containing all your static / JSP files under the WebContent folder. This will be deployed unpacked and will allow you to hot deploy everything under WebContent folder
There could be a better option than this one, but at least you will be able to work properly until you find something better.
I just created my first Web Application Project using the Google-Eclipse plugin. Amongst other artifacts, it autogenerated a war/ directory with several subdirectories and many files, including:
war/
WEB-INF/
lib/
<Lots of JARs here>
web.xml
appengine-web.xml
etc.
Several times now I've cleared out certain parts of this war/ directory (messing around with buildscripts and other Google-Eclipse plugin features - this is just a test/temp project for getting used to the plugin), and they magically reappear at some point in the future.
I'm wondering if, because I set this up as a Web Application Project (and it is thus managed by the Google-Eclipse plugin), is the plugin trying to preserve the structure of the war/, and as such, continuing to auto-generate any missing files?
If so, why? Exactly (which files/directories) what is it trying to preserve? Can I disable it?
And if not, then I obviously have something else going on here. In which case, has anybody else ever experienced this with the Google-Eclipse plugin, or just Eclipse in general? Thanks in advance.
This plugin only updates war/lib directory by adding dependencies. Actually it just copies jar files when you switch to a another version of Google App Engine SDK.
This should not be a problem.
War folder is the exploded package that later on you need to deploy to Google App Engine.
When you build or deploy file to GAE, this folder will be re-created/updated, and it contains the newly compiled jar and the necessary libs.
Read this.
War folder contains the generated javascript files which are deployed to the app engine.
What is the minimal conventional directory structure for a Java web app? What do I need to put in a build.xml file to get ant to build it and make a WAR file?
My goal is to deploy a Wicket app to Tomcat without using an IDE. I want to do it with only ant and my favourite text editor.
Maybe not the most minimalist possible, but the Tomcat project has an Application Developer's Guide with a section on source layout and a sample build.xml
Also, if you are starting a new project, you might want to check out Maven. With Maven, rather than crafting your own build scripts, you adhere to standard layout to do stuff, and then Maven figures out all the rest. It also manages dependencies, including its own. Learning curve is a bit steep, though.
Ours look like this:
web/
web/WEB-INF/ (sometimes we use a conf/ dir at the top level but this is minimal)
src/
lib/
The build.xml has three targets:
jsp: copies everything from web/ into the tomcat webapp folder and from lib/ into WEB-INF/lib
compile: compiles everything from src/ into WEB-INF/classes in the webapp
war: runs compile, jsp, and then zips the contents of the tomcat webapp into a warfile
This structure is a little bit informal and you can do it more cleanly by having a separate build directory for the warfile, and/or a separate compile directory, etc. Some people don't like the idea of deploying directly to the webapp instead of building a war first. But to get something up and running quickly, the above will do nicely.
You should check out maven. It's really complicated, but to build a war file it's simple, and there are plugins that will deploy the war to tomcat.