We Keep Coding

How to use clojure files dynamically?

I want use java code to run some clojure files dynamically which are in some zip files.
If the clj.p1.core.clj is on the class path, it can runs correctly.
require.invoke(Clojure.read("clj.p1.core"));
How to make it dynamically?That is, put clj.p1.core.clj in the a1.zip (maybe some files), the java program could select the zip and then run it?

Probably, you should unzip those files first and then specify a *.clj file when invoking Compile class; take a look at its sources.
What would be much better in your case is to compile a Java class from Clojure sources first and then load that class in Java as well. Just add a specific step into your build process that cares of it. In that case, your Java code will look much simpler and wont' waste time on loading Clojure code dynamically.
Creating a Java file would be easy; just wrap Clojure sources with additional namespace with gen-class declaration. Move its output into your Java project or specify classpath properly. See gen-class page for more examples.

How to create a runnable jar file from source code programmatically?

I need to create runnable .jar file programmatically from a string. My decision is to create a .class file from string and add it to the .jar using JarOutputStream.
What API must I use to create the .class file?
Are there any other solutions to create a .jar from the source code?

In order to do that, you can use the Java Compiler API.
There is this excellent tutorial that can walk you through.

To compile code, you need a compiler. You can either use the SunOracle compiler or the Eclipse compiler. Calling the compiler API (both have documented APIs) will produce a .class file in a temporary location. You can then make a jar.
For an example of this sort of thing, start with, for example, the Maven Compiler Plugin, which is a Java module which uses the compiler API. You'll have to find your way into the Plexus compiler module.

Eclipse always wants code to be in com\folder instead of com.folder

I have com.company.database.mysql and com.company.database.sqlite. I only want to include com.company.database.mysql.
My code was organized in folders (eg com/company/database/mysql) but now I want to have it flattened (eg com.company.database.mysql) so that I can include just the mysql code.
Eclipse doesn't seem to let me do this. It complains that the package is wrong "The declared package "com.company.database.mysql" does not match the expected package "" It only works if I unflatten it (ie com/company/database/mysql).
How can I get eclipse to work with code in folders named com.company.etc instead of subfolders?

The problem is that the Java compiler interprets periods in package declarations to be separate directories. So, if your file DataAccess.java is like:
package com.company.database.mysql
public class DataAccess {
}
The compiler will insist that this file be in a directory named mysql which is in a directory name database which is ... In other words your original directory structure:
src/main/java
com
company
database
mysql
That is the reason for the error. However you don't have to go to the lengths that you are just to exclude some of the source. You can manage your project's source path (Project properties > Build path) and exclude one or more directories.

You can't. The dots in the path are directory separators.
For compiled code you can store the class files in a jar. The directory path inside the jar will still be the the tree you have created.
If you really want to flatten the structure use a different character than a period. However, I would not recommend that you use such a non standard solution.

That's not an Eclipse thing -- that's part of the rules of Java, and thus is how pretty much every Java compiler works. It expects your files to be in folders named like com/company/database/mysql, and it's pretty rigid about that.
In order to change that, you'd need to either get rid of the package name, get rid of the dots in it, put your classes into a jar (which would still contain that directory structure, but you could just have com.company.database.mysql.jar rather than a folder), or change Java itself.

It's the convention of the java compiler that your source files are laid out in a particular way (depending on the platform/filesystem). If I understand you correctly, I think you are trying to go against that convention.
From http://docs.oracle.com/javase/6/docs/technotes/tools/windows/javac.html:
You should arrange source files in a directory tree that reflects
their package tree. For example, if you keep all your source files in
C:\workspace, the source code for com.mysoft.mypack.MyClass should be
in C:\workspace\com\mysoft\mypack\MyClass.java.

Managing Data Dependecies of Java Classes that Load Data from the Classpath at Runtime

What is the simplest way to manage dependencies of Java classes to data files present in the classpath?
More specifically:
How should data dependencies be annotated? Perhaps using Java annotations (e.g., #Data)? Or rather some build entries in a build script or a properties file? Is there build tool that integrates and evaluates such information (Ant, Scons, ...)? Do you have examples?
Consider the following scenario:
A few lines of Ant create a Jar from my sources that includes everything found on the classpath. Then jarjar is used to remove all .class files that are not necessary to execute, say, class Foo. The problem is that all the data files that class Bar depends upon are still there in the Jar. The ideal deployment script, however, would recognize that the data files on which only class Bar depends can be removed while data files on which class Foo depends must be retained.
Any hints?

This is one of the many problems Maven has already solved with it's build, dependency, and resource management. Any maven project follows a standard directory layout which dictates where you should put your Data files: in the 'resources' directories. The conventional Maven directory structure is as follows...
/
/src/
/src/main/java/
/src/main/java/App.java
/src/main/resources/
/src/main/resources/my.prod.data.or.cfg.or.whatever
/src/test/java/
/src/test/java/AppTest.java
/src/test/resources/
/src/test/resources/my.test.data.or.cfg.or.whatever
/pom.xml
The benefit of this is that all files which are contained in the 'main' (prod) resources directories are available to your application at run-time from the Classpath. All of the 'test/resources' files are available to your code during build & unit test time but are NOT included in your final artifact.

I don't think a generic solution exists for the system you describe, however, I just had a stab at reading annotations on classes using ASM, since that is used by jarjar as well. It is not hard to read the annotation data that way (pass in a ClassVisitor to the accept() method on ClassReader, and do something useful on the visitAnnotation callback). This means you can either try and include your intended behavior to jarjar or you could add it as a custom step to your build process.

Can't you refactor your project so that you have submodules that each contain the relevant files for the project itself ; Bar class and Bar related files will be packaged in their bundle while Foo ones will packed into another?
Another possibility would be to use some package naming convention to be able to filter the files you want to see i your bundles.

Why do Java source files go into a directory structure?

as weSuppose that I am creating a Java project with the following classes
com.bharani.ClassOne
com.bharani.ClassTwo
com.bharani.helper.HelperOne
com.bharani.helper.support.HelperTwo
with files put immediately under the folder 'src'
src/ClassOne.java
src/ClassTwo.java
src/HelperOne.java
src/HelperTwo.java
and compile them using the command
$ javac -d classes src/*.java (assuming that classes directory exists)
The compiler compiles these files and put the class files in appropriate sub-directories inside the 'classes' directory like this
classes/com/bharani/ClassOne.class
classes/com/bharani/ClassTwo.class
classes/com/bharani/helper/HelperOne.class
classes/com/bharani/helper/support/HelperTwo.class
Because the spec mandates that the classes should go inside appropriate directory structure. Fine.
My question is this: When I use an IDE such as Eclipse or NetBeans, they create the directory structure for the source code directory ('src' directory here) as well. Why is that? Is it mandatory? Or, is it just a convention?
Thanks.

Mainly convention. It makes sense for the source to mirror the binary structure.
Also, if you have two classes with the same name (but in different packages), how would you store the source if not in different directories?
Keeping the source in just one folder is fine for small projects, but once you have a larger project (hundreds of classes), grouping the source into packages makes things far more manageable.

Is it mandatory?
No
Or, is it just a convention?
Yes, to reflect your package structure in your source tree.
I always thought that Java's package is a little bit broken:
it seems to be hierachical, but it is not.
it is a simple (unique) prefix to define seperate plain namespaces.

I thought it was mandatory, but your experience suggests otherwise. Either way, it's just common sense, right? Large projects have so many source files - why make life more complicated by having different structures for your source and your class files?