Dependency Management in java using annotations

Question

I use maven quite extensively on all my java projects (and some non-java projects as well). However, I am a big fan of moving configuration out of XML files and into the java source files using annotations. I recently found the following on the Groovy Grape page:

Add a Dependency

@Grab(group='org.springframework', module='spring', version='2.5.6')
import org.springframework.jdbc.core.JdbcTemplate

Although this is Groovy code, it seems the above shouldn't be entirely impossible in Java. While it seems unlikely that this could (or would) be built into javac itself, it is something that could be built into Maven or some other build "wrapper".

What are your thoughts?

EDIT: It just occurred to me that annotations are not valid on import statements in java. This does present a problem...

Answer 1

You can build an annotation preprocessor to analyze your source for these types of annotations. Check out the Javadocs here .

Answer 2

I don't think you would like the idea of annotating all your classes with dependency annotations. This is the reason why the classes are grouped into units called modules or projects so that the import or dependency resolution of one artifact is usable across all the classes within the particular group or module.

However, you are likely to become a big fan of Gradle. Though it's not exactly annotations, Gradle addresses most of your concerns.

http://www.gradle.org/

Answer 3

Technically it is possible to write *.java files preprocesser on any language(groovy, python, antlr) that will process files and generate pom.xml(better just fill dependency section in existed pom.xml) on the base of annotations and module structure(annotations should be commented to do not disturb java compiler and IDE highlighting, like old XDoclet). I suppose this is idea for your own project). However from my point of view it is bad idea. What happens if you want to change spring version? Should you scan all project files and replace it and after that recompile. Build and configuration should be separated from code.