In my previous post I proposed a new ENSIME configuration format, to support the inclusion of Maven, Ivy, and sbt dependencies. Since then I've noticed that external build specifications are also useful for launching the REPL and the debugger. Specifically, one needs to know the runtime dependencies of the project, which are often different from the compilation dependencies (usually a super-set of). I've modified the .ensime file format so that Maven,Ivy and Sbt users are better able to utilize their existing build configurations in ENSIME.
Here's an example .ensime, for an sbt project:
(
:server-root "/home/aemon/src/misc/ensime/dist"
:server-cmd "bin/server.sh"
:use-sbt t
:sbt-compile-conf "compile"
:sbt-runtime-conf "runtime"
:project-package "com.ensime"
:debug-class "com.ensime.server.Server"
:debug-args ("/tmp/ensime_port.tmp")
)
This configuration will cause ENSIME to use the "compile" dependencies for building and the "runtime" dependencies when launching the REPL or debugger. The :use-sbt directive also sets default values for the :sources and :target directives (which can be overridden if needed).
A similiar maven configuration would look like this:
:use-maven t
:maven-compile-scopes "compile"
:maven-runtime-scopes "runtime"
And for Ivy:
:use-ivy t
:ivy-compile-conf "compile"
:ivy-runtime-conf "runtime"
The options available are fully explained in the .ensime.example file in the root of the distribution.
Wednesday, June 30, 2010
Thursday, June 10, 2010
Maven and Ivy and sbt, oh my
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.
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:
Posts (Atom)