Develop Reference

Location of generated source files for maven directory structure

Besides src/main/java folder, we have one folder that contains some generated java sources that are required for the main sources. Code generation is invoked manually, when needed. Generated source is checked into the source repo. Everything will be built and packed together.
What would be the best location for generated java sources that are going to be compiled together with main sources? Should it be:
/src/generated/java (following the same naming logic for src/testInt/java for integration tests)
/generated-src/main/java (in collision with "The src directory contains all of the source material for building the project")
/src/main/generated-java (well... generated-java is not a type)
...?
The first option seems like the most appropriate one for this case. What do you think? Is there anything in Maven docs that describes this situation (that I have overlooked)? Do you know any repo with similar structure?
Thank you.
Answer
As suggested by #Absurd-Mind, direction we are thinking about is to split the source into the submodules (which works nice in gradle). So, the generated source and some other related source will go into its own submodule (they will produce the separate artifact) and the rest will go in other submodule, that uses this one. Thank you.

I think the location depends on how the source is generated and handled.
The source code is generated automatically during the build process: Then i would use target/main/java/, target/test/java/ and so on. This code is not checked in into CVS since you can rebuild it fairly easy. In case you clean your project the target directory will be removed and the source will be rebuild.
The source code is generated manually by an external tool or similar: I would use generated/src/main/java/, generated/src/test/java/, generated/src/main/resources/ and so on. This code should be checked in. A benefit is, as soon you see that the top-level directory name is generated you know that all files/directories below are also generated. Also you have the standard maven directory structure under the top-level directory. Another point is that clean-up is easy, just delete generated and recreate it, without looking through many other directories (like in your example: src/main/generated-java and src/test/generated-java).
EDIT: Another nice solution would be to create a maven project which only contains the generated source like myproject-generated-1.0.3.jar. This project would be a dependency in your real application. Then you would just put your generated source int src/main/java.

As much as i know there is no standard folder structure for generated sources. In my projects, i prefer src/gen/java kind of notation.

I totally agree with the accepted answer. I just want to offer a slightly different suggestion for naming the directory that contains code generated by third-party tools:
src-gen/main/java
Background: In the Eclipse/Maven Tycho world (where code/resource generation often plays a large role) there is the src-gen directory for generated code, which has been established as some kind of standard convention. (the default project layout is a bit different compared to Maven, as all source files are directly in src and src-gen).
In a Maven project that could be translated for example to src-gen/main/java, src-gen/main/resources, src-gen/test/java, src-gen/test/resources. I like that more than moving everything into a "generated" directory, because
Sources in src/main/javaand src-gen/main/java are on the same depth in the directory tree
It's more clear that src-gen contains generated sources/resources that contribute to the build. On the other hand a folder just named "generated" dosn't tell you much about its content. It could contain anything, like generated documentation or generated test data or it could be just a temporary folder.
All the mentioned advantages of generated/src/main/java still apply (e.g. easy cleanup)
After a quick google search it looks like there are already projects on Github that use this pattern
Some thoughts/opinions about the other suggestions from the question:
Instead of /src/main/generated-java I would probably rather go with something like /src/main/java-gen which, when sorting directories alphabetically, keeps generated and regular code next to each other (<lang>-gen is also another pattern already used in Eclipse projects)
In my opinion gen fits in with the brief official names like src, it etc. more than generated. I've already seen src/gen/java a few times in the wild and have the feeling it is a more common than /src/generated/java. On the other hand some Maven plugins use the quite verbose target/generated-sources/<lang> directory, so generated-sources/main/java could also be an option if your not into short names...
Ultimately I think the naming doesn't matter that much and it is up to your preference since none of this is "official" convention.

NetBeans adopted <project>/target/generated-sources/<tool> as the location for generated code. As a result you would see an extra leaf appear in your project tree named as Generated Sources (<tool>), and source code will be navigable and not show up with compiler errors in the markup.
So if you commit your code, it will not be under the /target directory, and you will have to setup your maven project for the additional Source Code locations. Otherwise, I will suggest to keep with that adopted standard and put things under <project>/target/generated-sources/<tool>.

In Maven project source file store inside src/main/java , src/main/resources and test class store inside src/test/java.
In Maven generated code (Compile code) stored into target/ folder.
When you build your Maven project, all generated code to be updated in target folder.

How can I stop eclipse to modify .classpath automatically

I check out a java project from svn repository include .classpath and .project files. And I import these codes into eclipse. But the eclipse will modify the content of .classpath file. How can I stop eclipse to do this? just write off build automatically option?

You can't. But instead of putting a JAR on the Java build path you could
choose an execution environment which should stay stable when you change
the JRE and hence the .classpath file will not change either.

.Project and .classpath files should not be checked in under svn repos.Blindly copying such files from one machine to another may be risky. These are the files that eclipse automatically constructs for you as per your project structure. If you want to edit, you can do that.
Here is the nice explanation What's in an Eclipse .classpath/.project file?

Adding information to a 2-year old question just in case of any one else is stumbling across this.
Due to insufficient detail in the original question, I am guessing that the problem experienced is due to the project's classpath pointing to a different location on the questioner's machine as on the original project author's machine. When a project uses 3rd party libraries (JARs) and is shared between different team members (as hinted at by the use of a version control tool), this is a common occurrence.
A solution to this would be to have all team members set up the location of the directory containing all 3rd party JARs to have an identical structure on all individual machines. So instead of changing the classpath, change the directory structure to that required by the classpath.
Unfortunately this is not always the best solution:
Team members may have different operating systems (Windows vs Linux) and you will not be able to have a (absolute) class path that works on all platforms (e.g. C:\libraries\3rdparty.jar vs /opt/libs/3rdparty.jar)
Team members may differ in how they prefer to organize their directory structure. Especially, if a team member places libraries into his home directory (e.g. C:\User\abcd\libraries\3rdparty.jar or /usr/abcd/libs/3rdparty.jar), another team member will struggle to replicate that directory structure.
Eclipse provides various methods to set up a project so that it can easily be shared between team members. These however require team members to all agree on the convention, and will be slightly easier if set up by the original project author right from the start. Two methods most commonly used:
Add all third-party libraries to the project itself (the usual convention is to have a /lib directory inside the project for this - on the same level as /src and /bin etc.). The classpath can now be set up to be relative to the project's root and thus usable across different setups. A variation for large multi-project-file projects would be to have a separate eclipse project containing the libraries, then add it to other projects as a dependency ("Required projects on the build path" in the "Java Build Path" dialog).
This has the benefit of being able to version control your JARs too. However, it may use up a lot of extra storage/bandwith, so may not always be desirable. For instance, I would not do this with Java Enterprise Edition JARs contained in my preferred Application Server distribution, as I may want to migrate my project in future to a new version or another product, without such dependencies - I also do not want to have my project saddled with duplicate JARs that are in any case already available in the AS distribution. So you need to think through your requirements.
Eclipse also provides the concept of a classpath variable. This may be set up to point to the root of a team member's JAR-containing directory, and be extended with subdirectories and filenames inside the classpath. This needs to be done only once, and is also accessed via the "Java Build Path" dialog.
Whenever a new team member uses the project for the first time, he needs to configure eclipse (once) to point that variable to the relevant path on his own machine.
The above mechanisms are explained in more detail on various web pages, here is one reference: http://www.informit.com/articles/article.aspx?p=367962

Definining user libraries in Eclipse as part of a project and not a workspace

I saw that in Eclipse I can define User Libraries - to make setting the classpath easier (and probably for other reasons as well).
The problem is, that these libraries are only available in the workspace, and if I want other people using the same project to use them - I need to export my user library and they need to import it.
Is there any functionality like this on the project level? I basically need to have a 'classpath group' - can it be done?
If not, is there an automatic way to auto import the user library to the workspace when importing the project?
I'm using Eclipse 3.6.

JDT has the 2 concepts, user libraries and classpath variables. In the classpath variable, you can add jars to your project. Other team members have to fill in the variables in their workspace so their classpath is complete. This is useful when external jars might be in different locations on each team members local file system.
The USER_LIBRARY is a container for adding a logical group of local jars all at once. For example, the JRE_LIB container represents a number of local jars. But as you've seen, it points to a local set of jars meant to be used in multiple projects (as the JRE is added to multiple projects).
Aside from export/import (which you're already doing), I don't believe you can check CLASS_LIBRARIES into a project's SCM. If there was, the preference page would have a "Configure Project specific settings" link at the top.
Your best bet is to simply add the jars to the project, so they'll be included in the SCM. If they can be in different locations depending on the rest of your team, then use a classpath variable so it can be set in each workspace. That's the least amount of hassle as far as team members checking out the project and being ready to go.

The best way IMO is to use m2eclipse - Maven plugin for eclipse. In Maven all the dependencies are defined in pom.xml and downloaded automatically as needed. This means that the only thing you share with your team is pom.xml - your project definition.
There is a lot more advantages when using m2eclipse vs standard eclipse approch. More information is at http://www.sonatype.com/books/m2eclipse-book/reference/

The way I have used user libraries is for something like Ant. Define a user library "ant" for all the jars in ANT_HOME/lib. If including this in your Eclipse .classpath and then sharing with other users, they will get a build problem report until they create that "ant" user library themselves. It's useful, but you need to share knowledge on how to create the library. If you're using it for simple cases like above, then instructions for adding the right jars to the library are straightforward.
Another approach I've used is to build classpaths pointing into a folder (or folders) defined as a variable in Eclipse. See File -> New Folder -> Advanced -> Link to folder in the file system -> Variables. This lets you setup (again at workspace level) variable references to one or more folders. You can then build your Eclipse classpath/s with reference to the folder/s.
So say in your development environment, everyone needs to have a directory called "thirdparty" containing all the external jars dependencies (probably in hierarchy within that dir: thirdparty/apache; thirdparty/sun; ...). You define "thirdparty" as a variable pointing to wherever that dir is on your current system, you create a folder in your project/s using the variable. You can then setup (and share) classpath using paths into that folder.
It's similar to User Library and with similar limitations. The limitation is that the other users you share your project with must create variable folder/s as you have. But it's more flexible in that they don't have to add the jars explicitly as they do with a library; rather, your classpath/s in Eclipse point into the folder, as required for each project.
Note that although the folder variable is defined at workspace level, it can be reused in multiple projects, each of which builds their classpaths (.classpath files) with different references into the folder).
This is maybe something easier to show than to describe with words, but I hope it makes sense.

Easiest way to manage my CLASSPATH?

I'm beginning to play with Clojure a bit and my Java experience is pretty limited. I'm coming from the dynamic world of Ruby and OO, so the functional side of things is very interesting!
Anyway, as I discover libraries and various tools for use (and the tutorial files for the Pragmatic Clojure Book), everything typically calls for placing files in the CLASSPATH in order for Clojure to see the library for use.
Is there such thing as good CLASSPATH practice? Would I ever want to only have a CLASSPATH with just the external libraries of files I need or can I go ahead toss any library or file I would ever need in a directory and simply define it as my CLASSPATH and only require what's needed?
If it helps, I'm an OSX and Emacs user (Using slime and swank-clojure).

I recommend using leiningen and lein-swank to manage this. You can start a REPL in the directory and connect to it from Emacs.

Personally, I'm using a variant of a clojure-project elisp function by Phil Hagelberg, see source in this post to the Clojure group. It sets up the classpath appropriately for the project you'll be working on, then launches SLIME. (EDIT: You'll need to change the value which gets assigned to swank-clojure-jar-path to point to clojure.jar. I'm using (expand-file-name "~/.clojure/clojure.jar") as the default.)
To answer the question about having everything on the classpath all the time vs only throwing in what's needed: to the best of my knowledge, nothing will actually break if you take the first approach (I know I do that for experimental purposes), but apparently things might break with the first approach (see cjstehno's comment below) and in a proper project I find the second to be cleaner. At some point it'll be necessary to determine what libs are being used (and which versions of them), if only to tell leiningen (or maven) about it -- why not keep tabs on it as you go.

We are using Clojure and use a number of infrastructure tools, especially Eclipse (IDE) (http://en.wikipedia.org/wiki/Eclipse_%28software%29) and maven (http://en.wikipedia.org/wiki/Apache_Maven). maven manages libraries and jar dependencies so if you have a number of these and they are likely to grow start using maven.
In answer to your original question you can just put your jars in one directory and you can access them by name every time you run. But you will benefit from the tools...
If you are just exploring then Eclipse will probably manage your jar files fairly painlessly. You can add these to the project as required through the Build Path -> Configure Build Path option.
As your work progresses you will possibly wish to split it into Projects which Eclipse supports so you can add your (or other projects) to your Build Path.
If you use external Clojure libraries look to see if they have been packaged as maven projects (they will have a pom.xml file). The POM will give a list of dependencies.
#

The usual CLASSPATH practice for Java is to put only the jar files needed for a project into this projects class path, which means to have potentially different class paths for diffent projects. This is usually managed by the IDE as part of it's project properties.
Since you are using Emacs and thus probably don't have or use something like projects it might be more convinient for you to set up and use a single global class path for all your clojure related stuff or maybe even simply put all the needed jar files into the java2se/jre/lib/ext directory of your java installation.
The two main problems that could arise from having unneded jar files in your class path are: 1. it has a minor negative impact on the start up time of the JVM and 2. it becomes more difficult to make sure that you are not having classes with different versions in the same class path (i.e. different classes with the same package and name in different jar files).

Since Java SE 1.6 (or JDK 1.6) you can include class path entries by wildcard. If your class files live in .\bin, and your library jar files live in .\lib, then on Windows you could define your class path like this:
set CLASSPATH=bin;lib\*;
This will let you add jar files into the .\lib directory and they will automatically be added to the class path for new instances of the JRE.
See this link for details: Setting the class path
Prior to JDK 1.6 you had to add each jar file onto the ClassPath individually.

I just discovered this bit which I need to give a shot:
(setq swank-clojure-extra-classpaths (list "/class/path/1" "/class/path/2" "/class/path/3" "etc"))

clojure-contrib/launchers/bash/clj-env-dir has an interesting property that you can point it at a directory and it will basically include anything in there. In the past I've had a ~/classpath directory which I would dump any jars into and link any commonly used directories and it worked great. Very simple way to dump and use. Now I tend to use Maven clojure-maven-plugin and that works well also though can be a bit tedious when you just want to muck around with some ideas.

How to set up multiple source folders within a single Eclipse project?

I have several somewhat separate programs, that conceptually can fit into a single project. However, I'm having trouble telling Eclipse to make several folders inside a project folder.
A simple form of the structure would be:
/UberProject
/UberProject/ProgramA/
/UberProject/ProgramA/com/pkg/NiftyReader.java
/UberProject/ProgramB/
/UberProject/ProgramB/com/pkg/NiftyWriter.java
That is, ProgramA and ProgramB are both projects (in fact, they're currently existing Java projects), which conceptually fit into UberProject.
I don't think I'm supposed to make UberProject be a Java project; it's not a classpath, for instance. ProgramA and ProgramB do seem like they should be Java projects (they might use different build dependencies as well), but I see no way in Eclipse 3.3 to create two folders under UberProject that are intended to contain Java code. I thought about adding a .project file to each of the two sub-projects, but I'm not sure that's appropriate, either. Eclipse help isn't being helpful, and I didn't see anything on SO about this specific problem.
Just to be clear: assume as given the necessity of the existence of UberProject. UberProject can be a Java project, or not; it doesn't matter. (Incidentally, it does contain other folders that do not contain Java code.)

There are probably several ways to do this:
1) UberProject is your JavaProject. Right click ProgramA -> Build Path -> Use as source folder. Right click ProgramB -> Build Path -> Use as source folder. Both ProgramA and ProgramB will do incremental builds to the same directory.
2) Two java projects (ProgramA and ProgramB). You can use UberProject as your eclipse workspace which would be easiest or you can use an outside workspace and import ProgramA and ProgramB as external projects.
There are probably other ways as well (maven multi-module project). Your choice probably depends on whether you have cyclic dependencies between projects. It should be relatively easy to try both 1 and 2 and see what works best for you.

You can have multiple source directories in a single project, but your description makes it sound like you want multiple sub-projects in a project, which eclipse doesn't allow (as far as I know).
If you really just want multiple source directories, where ProgramA, ProgramB, etc. contain only java files and nothing else, then you can do this relatively easy. Right-click on your project in the package explorer, and select Build Path -> Configure Build Path.... In the dialog that pops up, make sure Java Build Path is selected in the left pane, click the Source tab, then click the Add Folder... button. Pick ProgramA from the list, and repeat for ProgramB, etc.
If you want each source folder to have its own output folder, just check the Allow output folders for source folders checkbox and edit the output folders as desired.
If that is not, in fact, what you want to do, then another option might be to group your projects into a working set. A working set is not an UberProject, but it does help keep your projects organized in the package explorer.

Do you need UberProject? I have the same layout but have multiple top-level projects created with File|New project. If not, can you make it a General rather than Java project?

So you can do it via having two Java projects in your workspace.
Then the question is how to group the two projects together under "UberProject"
One way is to have an "UberProject" workspace, and switch workspaces between UberProjects.
An alternative is to define "UberProject" as a working set (Window:Working Sets) and add PrmgramA and ProgramB as projects of that working set. Select that working set, and you see only those projects.
You can have one java project, and define multiple source folders for it. That is normally do that for "main" vs "test" hierarchies within the same project.
There are ways, and ways. Pick one that works for you :-)