Develop Reference

Which .JAR do I use to embed Jetty?

I'm at the point in my application where I would like to have an HTTP Server embedded into my project that updates the page in real-time using AJAJ(Similar to AJAX). However, I have no idea where to begin and the amount of tutorials on this subject are fairly limited, so I decided to go with a name that I've heard quite a few times before, Jetty
So, I downloaded Jetty and read through some documentation, and I'm staring at their beginner tutorial asking myself, "Which one of these f*kin jars do I use?" There's like 9,001 of them. Not to mention that there's like 1200 folders that all contain 1500 more jar files each.
Okay, I'm over exaggerating, but take a look.
It's fairly, uhm... confusing. This is much different than most libraries that are a single jar file, this is just... insane.
Anyway, I'm trying to figure out what all I need to be able to use JQuery, AJAX(AJAJ), and basic HTML features.

I'd suggest you to start with this simple tutorial and jetty-all jar
Embedding Jetty Webinar recording
Embedding Jetty docs
jetty-all different versions downlad

To followup on Gas's answer.
jetty-all doesn't have 100% of Jetty.
It used to, hence the name.
However, today its impossible to have 100% of jetty, as many components can conflict with each other.
If you use maven, or gradle, or ant+ivy, then you'll likely want to depend on:
org.eclipse.jetty:jetty-webapp
org.eclipse.jetty.websocket:javax-websocket-server-impl
let the transitive nature of those build tools pull in the rest.
This would get you "started" easily enough.
There are also plenty of example projects that use embedded jetty.
See:
Embedded Jetty: with JSP enabled
Embedded Jetty: with various WebSocket configurations
Embedded Jetty: using Servlet 3.0 features
Embedded Jetty: using Servlet 3.1 features
Embedded Jetty: various Logging configurations
Some use 100% embedded jetty (without a war file, or WEB-INF, or web.xml), some use a war file built elsewhere.
Jetty uses maven so it can participate in the global central artifact repository, and that we have 2 developers on Jetty that are also developers on Maven.
If you want to manage the dependencies yourself, then you will need to know intimately the purpose and role/purpose/relationship/requirements of every jar file that you are going to add into your project. (and answering that is way out of scope for stackoverflow)
You have many build tool options to make managing the dependencies easier:
Apache Maven
Gradle/Grails
Apache Buildr
Apache Ivy (an add-on for Apache ant)
Groovy Grape
Scala SBT (for working with Scala on top of Java)
Leiningen (for working with Clojure on top of Java)
Maven isn't required, you could use any of the above tools.
Tip: Maven and Gradle are the best integrated in various IDEs (like Eclipse IDE and IntelliJ)

Packaging and deployment of Single Page Application with java backend

I'm doing an app that has jee6 backend (json-based api only) and a lot of client side code. It looks like Single Page Application (this cool buzzword these days).
I'm not sure how to structure my codebase. There are ways I consider
have separate projects for backend and frontend - this means having backend part in pure java, with maven and all that stuff and have separate frontend with all the js-specific build tools etc.
have everything in one project, so that I can get one archive (war) to deploy on server with all the frontend stuff inside. I don't really like that approach...
What about the deployment if I go with the first one? I'd have to build another "war" archive from this frontend part and drop it on the server?
I couldn't find any practices people use.

I would leave your Javascript and CSS package with the WAR and use something like Wro4J (I have my own asset pipeline code I can share at some point).
Heres why:
To ease development you'll want the Javascript/CSS to refresh when you edit them while you run your servlet container. Maven, Eclipse (and/or JRebel) resource refresher will not work with weird package management.
There isn't really any thing like a WAR/JAR for Javascript/CSS only minification (Require.js and JAM are more for dependency loading).
The reason you have separate Java code in separate projects/jars is to avoid coupling, improve reuse, and increase cohesion. What your trying to do for separation is mainly for cohesion. In large part you don't need to separate the Javascript from your Web App because its already probably very separate from the Java and is a completely different language/runtime.
However I can understand if you say wanted to CDN your JS/CSS and why separating the code might be easier for experimenting.
Here are two options:
Git's submodules and have the Javascripts and CSS as separate projects that are submodules to your WAR project.
Have two WAR projects. One with your backend Java code and another with your frontend code. You'll need a container that supports multiple WARS and you will have worry about managing the dreaded servlet container context path.
I have actually done number #2 (laugh at that one) at a previous company I worked for. It worked pretty well. However now days I prefer #1 for its quickness and ease (laugh at that one).

Work on application and library simultaneously?

I'm new to java programming and I would like to work on some kind of game engine / lib. Just as a hobby project / experiment. I would like to make some sort of library with classes and utility functions to be able to re-use some generic game code and then a seperate application where I would build the actual game.
I am using intelliJ as an IDE. I was wondering if I could use, change and test a library with an application at the same time and how I would do this?

There are two aspects here. The technical: How does it work? The organisational: Is it a good idea?
The technical is quite easy. You just create different projects. The application project depends on the library project. Libraries are packaged as jars typically. Easiest would be to use a tool that supports you with dependencies and different versions of the library. I would recommend Maven for this.
The second question is harder and probably belongs to https://softwareengineering.stackexchange.com/ as it is more of a philosophical kind and no definitive answer exists. In my point of view it is a bad idea to develop a library and a product at the same time. Specificals of your product will slip into the library, you will get problems with priorities.
That is, when you are developing a library that should be used or published independently of your application. Modularisation of an application is another cup of tea, but could be done with the same tools. With Maven you would setup a multi module project then.

What do you mean by a library? A JAR right, a JAR contains a set of classes, what you would do is to "use, change and test" the classes you would like to make a library and when everything is done, you package it as a JAR and there you are done! If you want the JAR to be created everytime you "build" try using Maven or Ant that does these packaging tasks for you automatically. Maven is more powerful and you would love to see that it mainly does "dependency management" and your library is the dependency for your project.

Best practice for configuring a shared library between multiple dynamic web projects in Eclipse

I'm using Eclipse with Tomcat 7.0 and everything is working well. I have 3 webapps I'm developing and all 3 apps use the same set of source code from the same package (e.g. com.mycompany). So far I have 3 copies of the package, one for each web app, in each respective project folder. Each web app is intended to be standalone if needed.
What is the best way of configuring Eclipse Helios to have each dynamic web project use a shared library, which is also under constant development as well?

I think this can be an answer?
Link additional source
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-WorkingWithExistingLayout4.htm

Well...it's a simple enough answer...just keep the library in a single folder and import that into your project using an absolute path...however, note that this will be a problem when you are deploying the application in a different environment...

Managing a Large OSGi Application

I have a large, growing OSGi application with a number of bundles. I am curious to know the best way to manage this type of application. Currently, I am using Eclipse and Maven, but although this is great for building bundles (via maven-bundle-plugin), as of now it has not been easy to manage the entire application.
What I would like to do is either have ONE run configuration or ONE pom.xml that can be launched and the entire application/project be built and launched. Also, I would like to have something that would be good for debugging.
I have heard of PAX Construct and have it installed in Eclipse, but so far it has been of little help (maybe I'm not using it correctly).
I am sure there are people out there with large OSGi applications that are being managed correctly. Any advice that could be shared would help tremendously.
Thank you,
Stephen

A run configuration is possible via Pax Runner. It lets you choose OSGi platform implementation, specify profiles (pre-packaged sets of bundles for some role, e.g. web, log, ds, etc.) and has good provisioning support, for instance it can load bundles from Maven repository. As a result, you can have a run configuration like
--platform=felix
--log=INFO
--profiles=scalamodules,ds,config,log
mvn:com.my/bundle/1.0.1-SNAPSHOT#update
# other bundles
In case your application is very large or you have different applications, there a way to create own profiles as well.

Well...
It all deopends on what do You mean by "managing" the application.
For dev time launching, building and debugging - Eclipse IDE should fit the bill just perfectly.
Maven... I can't speak for it, as I've never used it myself.
We have a pretty large eclipse based application (several, actually) and on the dev side of things we are not using anything special besides the Eclipse and it's integrated SCM.
In the cc build server, we also use headless eclipse to do the building and packaging.
Now the setup of the workspace has gone a bit out of hand of late with all the dependencies and intermediate build steps, so we are investigating Buckminster for managing the materialization of target platform and workspace resources.
If that works out, we'll probably move to building with Bucky as well - it sure looks promising.
(I do not have any experience with PAX, but at a glance, it looks promising as well...)

i'm quite new to OSGi but,
wouldn't it be possible to use OBR-service in such a way that
you would have one OBR repository file which needs the bundles
and let the OBR-service figure out the dependencies and populate your OSGIhost for you?

This area I think has very poor support at the moment. OSGI doesn't really define anything about deployment or packaging so its up to other frameworks (e.g. Eclipse) to come up with their own way of doing it.
If you are building an RCP (Eclipse base) application, then the eclipse systems do all this stuff, right down to creating exes etc. However builds are mainly done on the Eclipse workspace, headless builds are trickier. The Tycho project is trying to make this more sensible by joining the Maven and Eclipse build cycles, however it is still focussed on RCP applications rather than generic OSGI.
If you not doing RCP, which is my situation as well, then you probably have to roll your own solution, as I haven't found any general solution. Here's an outline of what we do:
We define one POM project that lists all the bundles that are contained in your application. All this project does is list the references - lets call it the 'bundle-list' project.
Then, we use pax provision to run the project in development mode. This is achieved by making the 'bundle-list' pom the parent of the provisioning pom of the pax project (usually in the 'provision' folder). Then, when you start pax, it uses the list of bundles from that project to start OSGI. The bundle references in the 'bundle-list' project have to be marked as 'provided' scope for this to work.
Then, to create a distribution, we have another project. This project also has the 'bundle-list' project as its parent. This project uses various plugins to create a distribution, including downloading the bundle jars. The distribution includes scripts that start up OSGI, but these are hand written, there's no pax systems here.
This works well for us to keep the list of bundles in one place, but there's still a lot of hand written scripts, and there are issues sharing configuration between the two systems - e.g. config files, bundle start levels etc.