One of the goals of ENSIME is to provide support for common build systems, so that you don't have to repeat yourself (too much) when describing your project. At the same time, we want to stay decoupled from any particular build system.
I've been sketching out some changes to the .ensime config format:
(
:server-root
"/home/aemon/src/misc/ensime/dist"
:server-cmd "bin/server.sh"
:server-host "localhost"
:project-package "com.ensime"
:source (
:include ([files or dirs(recursive)])
:exclude ([file or dirs(recursive)])
)
:classpath (
:ivy [ t | nil ]
:mvn [ t | nil ]
:sbt [ t | nil ]
:jars ([files or dirs(recursive)])
:dirs ([dirs])
)
)
The :ivy and :mvn options would cause ENSIME to search for "ivy.xml" or "pom.xml", and analyze these files for dependencies. The locations of these dependencies in the local ivy or maven cache would then be added to the classpath.
The :sbt option would cause the jars in the 'lib' and 'lib_managed' directories to be added to the classpath.
The :jars and :dirs option would act as a fallback when the above options are not sufficient.
I think it's important that ENSIME _not_ try to do the work of a build management system; that problem is already well solved. Hence, there are no plans to try to resolve and download dependencies.
Subscribe to:
Post Comments (Atom)
This is beautiful, and really important. "Its important to do one thing, really really well". Let build systems take care of building and library management.
ReplyDeleteAnd maven, ivy and sbt are the way to go, at least IMHO.
Just remember to let us know when it's ready! :)
Why not just use sbt's project API underneath? It provides what you're trying to do with ivy/maven and more. I'm not sure that sbt's project format is any "worse" than the .ensime config format....
ReplyDelete