We Keep Coding

Package Simple Java Programs with assets, etc

I am about to ship a simple/medium sized java SE application to a little company.
As I am a student and mostly working on Android stuff, I never had to deal with the problem of packaging assets and folder structures within a java application.
My main concern is packaging some assets (e.g. pictures) with it. On the other hand I wanted to setup a little file structure for logs etc.
Are you using some kind of installer for that?
Or do you package the images etc. in java-packages and reference to them relatively via .class.getRessources() stuff.. and thus also setup the directory structure in the application itself?
What do you think should be "recommended practice"?
I hope this question is not to general. Thanks in advance for your thoughts.

Depending on the resources size, you can either place them in your project under the resources directory and refer to them using some getResource variation, or you can store them somewhere online (Amazon S3, your own hosting) and refer for example by web request.
For small resources the best practice is to put them inside the resources directory.
You should package your project as a jar, either by directly using the jar command, or by using maven to do it for you, but in this case you'll have to setup your project as a maven project, here's their famous 5 minutes guide.
After you have your project packed as jar (or jars) you can upload it to the maven repository, or use other sites which allow you to upload your binaries, such as bintray.
Or you can just send the Jars by email or put them on your own hosting or something :)

Try maven.
For example, with maven you can use android plugin, which can run tests and log operations for your android apps
Using maven/gradle - its core skill for all cool java developers.

How to continuous UI development in java?

So I come from ruby on rails background.
I am working on this java project.I am fairly new to java.
I maybe wrong but It seems unlike other technologies ,one compiles the project in a war file then deploy's that on tomcat.
The original assets are in src directory that are be checked in the source directory.
Where as to make any changes in assets files that being css/javascripts/images one need to
make changes in the target directory of the tomcat to preview them on the browser.
This makes development tricky and complex as I can't use branches, since branches work on src directory of my local repository but the changes I make are in the target directory. Also I would like to use sass and haml like features in java. What frameworks or other web servers or any other strategy are my options .
I have heard of groovy on grails but for some reason we want to stick to java the language

Look into using a build tool like maven or gradle to build your project. They both have a jetty plugin with a jettyRun goal that will run your project out of your source directory using embedded jetty. So if you are making changes to the assets, you just have to refresh the browser.
Another alternative is to configure tomcat to serve your assets up as static files from your workspace while you're doing development.
Or as #DaveNewton suggested, you can use your IDE to auto deploy

How are Java applications deployed in the "real world"?

As a novice to the world of Java programming, this question has always boggled my mind. I first believed that all Java files were compacted into applets and then ran, but I soon realized that this isn't always the case. Could someone explain to me how we actually interweave our Java applications into a real product of everyday life?
TL;DR: How do we implement our code for practical usage?

It depends on the application. There are many options depending on how you want your users to use your app. Usually it's packaged as a jar or a specialized jar (war, ear).
In theory, you could zip the raw directory structure with your .class files in it and provide a shell script/instructions that run the java command for the user. I don't recommend this because it's kind of unprofessional and requires you to maintain a shell script for each OS you want to be able to run the program on.
Jar files are used to package libraries but you can also have a manifest file in it that says, "When someone double clicks/executes this, run this class". That class can start up a GUI or be a headless task that responds to the parameters, etc.
You can have applets, like you said. These programs are run in the user's browser.
You can have a war file, which is a way to package a web application. You give this to a web server and it knows how to deploy it so that you can visit the web pages. An example web server/container is tomcat or jetty.
You can have an ear file which can contain other war files inside it. This is used for applications that need other parts of the javaee functionality (ejbs, jms queues, etc.). An example of an application server is jboss or glassfish.
There's also java web start apps. These are apps you can run by visiting a webpage, but they get downloaded to your computer and run on the user's computer (instead of on the server's backend, like in a war/ear).
There's also javafx. I don't know anything about that though. By skimming the FAQ, it appears to be Java's answer to Adobe's Flex. You configure UI components with an xml configuration. I'm not sure what format JavaFX apps use, but it does say, "Deploy on the desktop or in the browser".
As Sotirios Delimanolis mentioned in a comment below, you can build these files with build systems like Ant or Maven. You can also build them "by hand" with the tools that come with the java/javaee sdk. For example, you should have a jar command in your path if you installed the sdk. Here are some details of these build systems:
Maven
High level (you tell it what to build, not how to build it)
Much more than just a build system. It also has dependency management, etc.
Opinionated (it uses convention over configuration, each config file generates 1 artifact, etc.)
Ant
Low level (you tell it how to build things)
Flexible
Config files can do whatever you want, build as many artifacts as you want
Easy to learn
SDK tools
Always up to date. EG: Very rarely, maven/ant may not be able to set a configuration option
Difficult to remember commands
Very low level
By itself, not repeatable (EG: unless you build a script, you will have to type the jar command yourself each time)

Applets never really caught on and are very rarely used nowadays.
Simple applications can be deployed as "executable" JAR files , which are basically ZIP archives with additional metadata that tells the JVM which class contains the main method to run. They can be run on the command line using the -jar option, or in most desktop environments by double-clicking (this requires a JVM to be installed as well).
Desktop applications can be deployed via Java Web Start or installers like IzPack or Install4J, but Java desktop applications are not very common either.
Most Java software nowadays runs only on servers (web servers or app servers). They are typically deployed as WAR or EAR files, which are also ZIP archives containing classes and other resources. These applications then run inside a server component following the Servlet or EJB standards.

If the application is mean to run on a client, it is packaged as an executable JAR, then further packaged as an Application Bundle (Mac), maybe wrapped in an exe (Windows), or paired with an executable script that will launch the JAR and set any required VM arguments.
If it is part of a web application, then it will be packaged as a WAR or EAR and placed into the appropriate location on the web server.
If it is simply a library, then it is usually packaged as a JAR (non-executable) and distributed as such for integration into larger projects.
applets and then ran, but I soon realized that this isn't always the case
Actually, applets are rare nowadays and their use is discouraged.

Create an executable jar, a war which is dropped into a web server or a library that is used by another project that is one of the previous two.

what are the steps in order to run java enterprise application

Sorry for this simple questions but i am too much confused with how to run java application. Whenever i ask some each one tells his own tools to proceed and i have learn that thing.
So provided i have simple basic eclipse with no plugin and i have downloaded the sample web application which uses spring , hibernate , mysql ,
The folder structure of app is
.setting
src--main,test
target
.classpath
.project
Now i want to run this using localhost in browser
what thing i need to do. i will tell from my knowledge and u guys can correct it
i don't want to use STS or install any plugin in eclipse.
I imported the project from eclipse
menu and i appeared on left window
As it uses spring do i have to add
the spring jar files in build path
of spring. or anything else
Same for hibernate jar files
Fior simple java app i used to
compile the class which contain the
void main function but i have no
idea which file to compile to run
this app
I added the mysql connector in build
path to connect with mysql in simple
java app. will same thing work here?
I knoow we need web server for that.
so if i want to install glass fish
server then how will i connect it to eclispe or that app. will tomcat be
ok than glass fish??? i know tthere
is eclispe ide with embedded glass
fish but i want integrate evrything
myself
IN browser i which url i need to use
to see that app
I don't know how did maven , appfuse fit in here. Can i run app without maven if yes then what does maven really do , i mean does it compile the java files or what. If i require maven then
Do i need to install it separately i
mean exe file or jar file
how to link with eclipse
I have read about building with
maven , what will ahppen after
building i mean what is the result
of building , will i see browser
after building or after building
there are some steps further. do
maven needs to link with web server
installed
sorry for basics questions but i am confused with all new trminology

Building a webapp is complicated. I will try and address your specific questions.
Utimately you don't need Maven or Appfuse, both can be very helpful.
Maven is a build tool. Maven and Eclipse do some similar tasks. Both can compile your code and manage a classpath. Maven handles a lot of things out of the box that Eclipse can't do by default. Maven can manage dependencies (i.e. download the spring jars for you) and create complex build processes.
If you are unfamiliar with Maven and creating a build file from scratch then it probably won't be much help. If you have a pom.xml (Maven build file) from somewhere else then Maven can be a big help. The result of Maven depends on how your build file is structured. The result is most often either a .war file (described below as step 5) or that your application is deployed directly to your web server (described below as step 6).
Appfuse is also not mandatory but can be useful. Appfuse will create a skeleton project for you. When it does this it will create a pom.xml (Maven build file) to automatically build your project. Appfuse by itself doesn't do anything other than help get projects started. Most people don't start building web apps from scratch anymore since getting the directory structure right and creating the build file can be a lot of work and it's easy to make mistakes. A tool similar to Appfuse is Spring Roo.
Tomcat, Glassfish, Jetty, and JBoss are web servers. They are also often called Servlet Containers which is just another name for a web server that hosts servlets in a certain fashion. Any of them will work for your project, they all have different learning curves. Integrating them into Eclipse may work for you, when I got started I found it was easier (although a little slower) to keep them separate.
In the JDK there is an interface named javax.servlet.Servlet. This is the interface that the entry class of your web application must implement. In particular the method service(ServletRequest req, ServletResponse res) is called every time there is a request for a URL. If you want your web application to respond to HTTP it may be simpler to extend the abstract class HttpServlet (which implements Servlet) instead. Most libraries (i.e. Spring web framework) have their own implementations of Servlet that are the entry point to the library.
I will now describe the basic process for building a web application. This is a complicated process and most people eventually automate it with Maven. I do not suggest trying to manually walk through the process yourself it can be very complicated but you can if you want. I am going to assume that you are placing all of your built files in a folder named $BUILD
Compile your source code. The compiled classes need to end up in a folder called $BUILD/WEB-INF/classes
Place all your jar files (external libraries) in a folder named $BUILD/WEB-INF/lib
Create a deployment descriptor, this is a file that tells your web server how to deploy your code. The most important thing in this file is a mapping from URLs to Java classes that implement Servlet. It should be named web.xml and put in $BUILD/WEB-INF
jar up the all this code with the root of the jar being at $BUILD. You could call this code application.jar
Rename the jar file extension to war. A war file is simply a jar file that has the required WEB-INF directory inside of it.
Deploy this war file to your web server (Tomcat/JBoss/Jetty/Glassfish/etc.), the process for doing this is different for each web server
That is the basics of web application deployment. Your web server will extract the war file and load all of the jars in the lib folder into the classpath. It will then take any URL requests it receives and send them to the appropriate Servlet implementations declared in your deployment descriptor.
As you can see this is not a simple process. This is the reason tools like Appfuse and Roo exist. They try and give you a starting point which does all of this basic stuff for you. If you are having trouble I would suggest trying again from scratch with Appfuse/Roo. As you start to get the hang of things I would also suggest learning more about Maven (or Ivy+Ant) to handle dependencies for you.

You should download the Java EE edition of Eclipse - it contains the code needed to work with enterprise applications.
You will also need an enterprise server (like JBoss or Glassfish) and the corresponding server adapter, which is a bit much for a beginner.
The easiest way to get started is to download Netbeans with Glassfish and use that instead - at least for now - as everything is configured correctly and it is very fast to get started! When you are more familiar with the way things work, you can switch back to Eclipse if you want to.

Eclipse: Have multiple Dynamic web projects contribute to a single war file?

I am in a situation where I basically want to be able to have a web project in Eclipse where the WebContents folder is merged from multiple projects instead of only a single dynamic web project.
If I have "a.jsp" in project A, and "b.jsp" in project B, I would like to end up with a single web application in the web container where "a.jsp" and "b.jsp" sit next to each other in the same folder. It would be perfect if all files, not just the jsp-files, could be merged like this.
This is to be able to have a core version of our application but being able to handle customer specific changes easily.
I know I can do this with suitable ant magic, but we want to have something that works well for our current Eclipse based development process. We will use JSR-330 dependency injection on Java classes, and essentially I'd like something along the lines of dependency injection but just for any resource and not just classes.
Can Eclipse do this?
If Eclipse cannot, would an EAR deployment be suitable perhaps? I currently have experience with WAR's only.

If using Maven is an option, then Maven overlays would be perfect here and it should theoretically be supported by the m2eclipse plugin. But I don't have any experience with that and there might be some issues (see MNGECLIPSE-599) so this would require some testing.
Nevertheless, the comments of MNGECLIPSE-599 are pretty interesting, especially this one:
Any love for this issue? Our entire team has moved to Netbeans for WAR development because of this. We are basically waiting for Servlet 3.0 to solve this issue for us (Servlet 3.0 would effectively negate our need to do overlays in Maven) Our company is big on reducing copy-paste so we use overlays to manage WAR media that must be common in our apps.
The way Java EE 6 would make overlays obsolete is not crystal clear for me (through Web Fragments?) but the fact is that Eclipse's WTP release with Java EE 6 support has been delayed to June 2010. So, until then, you'll need extra tooling (e.g. maven overlays) or should maybe consider switching to NetBeans.

I had a similar use case which I successfully resolved by using (as Pascal suggested) Maven.
I have a root web project (which also works standalone) and for each client I have a separate web project which is configured to overlay with the root web project. Furthermore, since each client has several environments I created a maven profile for each environment (test, prod, local, ...). I documented this a bit so if ever you are interested I don't mind mailing you the doc.

you don't need to change your "eclipse based development process" to use ant. Just register an Ant builder (right click project > Properties > Builders) and integrate the ant script with your eclipse process
you can use maven's multi-module options. (The maven plugin for eclipse is very good as well)
use can also use FileSync - not industry-standard but pretty powerful. It's used for developing on localhost, of course.
Here are a few tips for using FileSync:
setup which files/file patterns/dirs to copy to a target directory (Tomcat's webapps/application in your case). So as soon as you press "save", the files are copied.
make all absolute paths in the FileSync.xxxx.prefs relative by introducing a Linked Resource (preferences > workspace > linked resources), and using the link resource variable in the prefs file (lets call it WEBAPP_HOME)
commit the FileSync.xxxx.prefs file
tell each developer on the team to configure the WEBAPP_HOME variable. Thus the setup will not be valid for only one machine, but for each machine in the team.

I recommend to use the servlet 3.0 "Resources in bundled jar files" feature.
With this feature you can include web resources (html/xhtml/css/js/jpg/etc) in jar files (along with java class files, of course) and the web server will search the "META-INF/resources" folders of the jars for the resources.
More details here:
http://alvinjayreyes.com/2013/07/28/servlet-3-0/