We Keep Coding

How to include Javadoc in a library JAR?

I'm currently trying to write my first own library. It's just for testing, I want to find out how libraries are written, compiled, distributed and used in order to prepare for some upcoming personal projects.
Yet, what really causes me to wonder, is why exactly my Javadoc isn't compiled with the Library. I know that comments and annotations are not compiled, but for example the JDK (which is basically a huge library) comes with a working doc as well.
I've tried to compile a JAR (libraries aree normally JARs, right?) from not the compile output, but the sources (so I had a JAR of .java files), but this failed to be included in IntelliJ. I could add it as an external library, but neither did it show up in my explorer, not could I import or use any of my classes.
I know there must be a mistake somewhere here, all libraries I've ver used, whether it was Java, C# or whatever else always came with a working documentation (IntelliJ shold show that on mouse hover), and I'd like to know how to correctly build a library that I can share with a team partner, so he just needs to download it, add it as a library in IntelliJ and has all the functionality, but also the documentation.
Thanks to everyone in advance!

Because it isn't needed, and would bloat the file size of the executable. If you have a library in C or C++, the documentation may be bundled in a zip file, but you won't find it in the compiled .so or .dll. One just holds the binary and resources needed for the project. The .jar is equivalent of that- it's the compiled output. Documentation is hosted/downloaded separately.
When you download the JDK, you're not just downloading a giant .jar. It includes other things, like documentation in the download.

I'd like to know how to correctly build a library that I can share with a team partner, so he just needs to download it, add it as a library in IntelliJ and has all the functionality, but also the documentation.
The short answer is that you provide your team partners with your project source code as well as the binaries. They then can configure their IDE (Intellij, NetBeans, Eclipse, whatever) with the location of the source code and the IDE will be able to extract the javadoc comments on the fly and render them as requested.
Sharing the source code also has the additional benefit that your partners can debug their (and your) code better. By themselves, javadocs are rarely sufficient for debugging complicated problems.

Alright, if everyone ever has this probelm again, here's a complete tutorial:
As #Gabe Sechan already said, the Doc is not compiled into the JAR for some valid reasons. Instead, I recommend you to add the following to your JAR:
module compilation output
content of "src" directory / alternatively: module sources
Build --> Artifacts --> All Artifacts.
Now, if you add your library JAR into a project, it will show "Classes" and "Sources" in the right tab, as IntelliJ automatically recognizes you've bundled both into the JAR.
Now, IntelliJ should show your documentation, as it lives within the source files.
If, for some reason, IntelliJ switches from its "fancy" documentation popup to unformatted plain text, proceed as follows:
Navigate to File -> Settings -> Advanced Settings, and in the 5th block, where it says "Documentation Components", just tick everything you find. That's gonna fix it.
Thanks to Gabe Sechan again, your answer helped me to understand what won't work, and finally I've found a way to make it work myself.

How to add a .zip library to Eclipse

I need to add an external library named ControlFX in my project. Here is the official link to download it: https://github.com/controlsfx/controlsfx
The issue is that this file is .zip type. So, I'm really confused about how can I add it as a library to my project (it doesn't include.jar files inside).
Any idea, please?

Check out How to add external library properly in Eclipse? if you want to add it manually, but it's very much not advised if you don't know what you're doing.
If you want to learn the proper way to use external resources look into how to use Maven or Gradle to incorporate libraries into your projects.

Why is my project not compiling?

I checked out a new version of my project from svn and now Java has made the easy thing difficult. I don't know what is wrong and I can't even build the project. What should be done? The code should compile, it's just not being picked up by the IDE.
And I couldn't run it with Java 7 but that might be a different question, now I can't even run it with Java 6 since Eclipse has made the easy thing difficult. Did I do something wrong when I checked out the project from svn? I use xp-dev.com

You checked out the entire repository instead of just one tag. You wanted to check out trunk.

Right click on your src directory that contains your packages and specify Build Path -> Use as source folder and it will set things up properly for you.

Maintaining Eclipse project include/lib paths in CVS

Background:
Here at the office my group uses a common linux environment where we do our code development. Our code is kept in CVS. The latest releases of our various libraries are kept in a specific directory (ie /data/group_projects/lib). Our Makefiles/Ant builds all specify what libraries are needed. We use autoconf to create the makefile after checkout for most C/C++ projects. We've just got Eclipse (3.4) installed and are planning to incorporate it into our workflow.
Problem:
So, when I check out a project from CVS through the Eclipse interface and then I have to set up all of the library paths (and include paths for C/C++). For some of our projects, this could be a lot of work. Is there a good way to save these paths along with the code when I check it back into CVS?
Ideally, when the next person checks out the code in Eclipse, the paths (and anything else they might need) will automatically be set up and they will be able to compile straight away.
Efforts:
I know that the include/lib path info is kept in a .cproject or a .classpath file (C/C++ or Java respectively). I thought I could export this info through Export -> Preferences. The resulting epf file doesn't have any path data in it unfortunately. I tried directly adding the .cproject file to one of my projects (so I could then put it into CVS) but Eclipse really doesn't seem to want me to do that.
I am quite new to Eclipse (esp using CDT), but maybe the necessary path info can be pulled out of build.xml/Makefile automatically by Eclipse? There seems to be a bit of a disconnect in Eclipse between the buildfile/makefile and the jar/include files that the IDE uses for checking your code as you type it. Maybe I am missing something?? I'm planning to put some serious time into researching Eclipse over the next few days so hopefully the inner workings will become much more clear to me.
I've asked the guys here at the office but no one is much of an Eclipse guru. My searches haven't turned up much . . I did see a suggestion to add all external jars to Java -> Build Path -> User Libraries under Eclipse Preferences. For us, each user would have to set this up once but afterward all of our java libraries would be available to whatever project we decided to check out. Unfortunately, it doesn't seem as though I can do the same thing for CDT.
What would you suggest? Am I missing a setting or function of Eclipse? Or am I going about this the wrong way? Please let me know what you think. I'd really appreciate it. Thanks!

You simply need to share the .project, .cproject and .classpath files through CVS. You can do this from the cvs command line, or select then 'Team/add file to version control'.
You don't need to add these files to the project explicitly: they are inherently part of it.
Obviously, if you do this, you need to make sure they are location-independent.
See:
eclipse wiki
Safari books

I've done this in Eclipse, and it's not too hard. You have to check in the .project and .classpath files. There are one or two places where Eclipse doesn't correctly automatically check out the files when you want to edit them, so when you get a read-only error you have to go manually do it, but for the most part it works.
The paths need to be all relative.
If relative paths is a problem, you can also take advantage of workspace variables in Eclipse. The developer sets their workspace variables appropriately on their machine (e.g., OPENGL_INCLUDE_PATH ), and then in the builder you can set the environment to pass that path along.

Getting Netbeans and Subversion to play together nicely with libraries?

I'm having a difficult time figuring out how to add a .jar/library to a Netbeans project in such a way that I can get it committed to the repository.
The typical way to add a library (per the Netbeans documents I've already gone through) ends up with it just being local to me. Anyone who checks out my project ends up missing my required library.
Inserting it manually and trying to work around Netbeans results in Netbeans hanging while trying to scan the project...
So, how can I tell Netbeans to pick up a jar as a library and include it in my project in such a way that Subversion will be able to handle it?

There are a couple ways to fix this.
A. When you define your Library, use a path to a common location. A location that's identical on everyone's machine--such as the location of a JAR installed with a third-party app into Program Files or /usr/local/ works well or a network drive.
Then, when they check-out the code, the path will still be correct and they do not have to define the Library on their Netbeans workspace.
B. Edit your project.properties file to use a relative path. Open your project.properties file and look for "libs.LIBRARY_NAME.classpath=...". That will be the "default" location used if the Library is not defined.
Change this to use a path relative to your project and store the jar files in your project. For example:
libs.Log4J.classpath=lib/log4j.jar
Keep in mind that the Library definition in your Library Manager will override this value--so make sure you keep them in-sync (i.e. append a version number to the library name!).
C. Use Vincent's suggestion of using a build-system such as Maven. The Maven build-process will take care of downloading dependencies, etc. Netbeans has plugins for several popular build systems.

There is a new feature in NetBeans 6.5 (variable-based paths in projects) which should make this easier.
See http://wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-VariableBasedPathsInJ2SEJ2EEProjects for details. Note the screenshot includes variable references in the library customizer.

Not really an answer to your question but... generally you should not include these libraries in your subversion repository. There is usually no need to have them managed. What you might want is to set up a central repository similar to what happens with maven. If you use maven, you can create a local repository of libraries on a server accessible by the team. The dependencies on these libraries are entered in the pom.xml file and this is in the subversion repository. Now, as team members check out the code from subversion they all have access to the maven repository.
[I am looking for a reference to this right now. When I find it I'll edit this answer.]

I use NetBeans IDE 6.5.1 and the best solution I've found so far is to include the needed libraries from your local host and then change their paths to relative. After that you have to remove the libraries manually from the NetBeans file explorer, and then copy them from their OS location in your computer manually to the file explorer again. That way NetBeans detects the change and you can commit it to the repository.
Note: I Highly recommend to clean and build the project again after updating.

An easy way to pack up your lib/jars into your project so that subversion "just handles it" so you can grab it out with all the attached libraries ready to compile and go is to include them all under your project directory via the "shared libraries" option by managing the libraries folder.
When creating a new project you can specify "Use Dedicated Folder for Storing Libraries" and then use the suggested relative .\lib path. If you have an existing project, you can edit it's properties, Libraries Category, and Browse for a Libraries Folder. Again a first-time run will suggest .\lib and then offer to copy existing dependencies to that folder. These graphical actions should provide similar results to James Schek's 'B' answer.
Commit the project with the newly added libs in .\lib and you should be able to checkout and build from anywhere and know you'll have the same libs (at the same version) as you had when you last built and committed.
I don't know how long this feature has been in NetBeans. For more details see:
http://netbeans.org/kb/docs/java/project-setup.html#projects-shared-libraries

I ended up just downloading my own set and putting them on my local drive for this project. I setup my Netbeans to look there and warned the other guys what I did... Eventually, we'll have to do something a bit more scalable though... :-)

OK, the working solution that I've now moved to is to extract the class files out of the jars and dump them into the Source Packages area. Then it all gets committed to the repository and also avoids having to deal with handling a separate "lib" directory in the deployment phase.
This solution does everything I'm looking for, yet I feel real dirty about doing it this way. It just seems horribly broken and wrong... :-)