I'm working on an extension for Buildr should make it easy for those
converting from maven. Currently the extension supports transitive
dependency resolution and pom generation. The pom include all declared
dependencies with the right scope. I've just started writing this
extension last week and I'm currently using it in one project, so expect
hiccups. A good idea would be to work on a different branch in your
project until things look good. The project is on github so take a look
and get involved if you need to improve it.
https://github.com/jvshahid/buildr-dependency-extensions
On 01/14/2011 10:10 AM, Mathias wrote:
Because compile.dependencies are not required to be artifacts. Some of the
elements may be but not necessarily all of them. Any code that processes
compile.dependencies must therefore take that into account. The code can
easily filter out artifacts if desired by running the list through
Buildr.artifacts() and filtering based on "artifactness" (i.e., elements
that respond to :to_spec / :to_spec_hash)
Hmm... this is strange.
This is the relevant snippet from my buildfile:
ASM = ["asm:asm:jar:3.3", "asm:asm-tree:jar:3.3", "asm:asm-analysis:jar:3.3",
"asm:asm-util:jar:3.3"]
SCALATEST = "org.scalatest:scalatest:jar:1.2"
define "core" do
test.using :testng
package(:jar).pom.from file("pom.xml")
package :sources
package :javadoc
end
desc "The Java DSL and supporting code"
define "java" do
compile.with ASM, project("core")
test.using :testng
package(:jar).pom.from file("pom.xml")
# package(:jar).pom.from create_pom(package(:jar), compile.dependencies)
package :sources
package :javadoc
end
desc "The Scala DSL and supporting code"
define "scala" do
compile.with project("core")
test.with SCALATEST
test.using :testng
package(:jar).pom.from file("pom.xml")
# package(:jar).pom.from create_pom(package(:jar), compile.dependencies)
package :sources
end
As you can see the java module and the scala module both define a dependency
onto the core module in exactly the same way.
Still, from the java module the "compile.dependencies" contains actual artifact for the
core module, whereas from the scala module the "compile.dependencies" contains just a
string referencing the jar location for the core module.
This is at least somewhat unexpected.
Not that should not be necessary. If you want to post code illustrating a
case that doesn't work, I'll be happy to review it.
Well, take this example here:
package(:jar).pom.content('---pom content---')
I would expect this to create a pom.xml in the module target directory
containing just the string '---pom content---'.
Instead the statement is ignored (or rather it produces output identical to a plain
"package(:jar)" directive).
Of course closing issue BUILDR-486 would be even better... :)
Agreed. It's high on my list but I'm in the last leg of a project crunch at
work so it will have to wait a little bit.
No problem. I understand.
Still I'm looking forward to 1.4.5 with the Scala 2.8.1 support baked in by
default.
Cheers,
Mathias
---
[email protected]
http://www.parboiled.org
On 13.01.2011, at 18:44, Alex Boisvert wrote:
On Thu, Jan 13, 2011 at 1:14 AM, Mathias<[email protected]> wrote:
In the definition of a Java-based sub project I can then do:
package(:jar).pom.from create_pom(package(:jar), compile.dependencies)
and the generated pom.xml is correctly being used.
However, from a Scala-based sub project the same does not work.
Firstly, the temporary pom.xml in the target sub directory is only created
if it doesn't exist yet. For some reason in the Java-based sub project this
is not the case.
Secondly, the compile.dependencies array for Scala projects contains just a
list of Strings (namely the file systems paths to the artifacts rather than
actual artifact objects responding to "group", "id", etc.)
Why is this the case?
Because compile.dependencies are not required to be artifacts. Some of the
elements may be but not necessarily all of them. Any code that processes
compile.dependencies must therefore take that into account. The code can
easily filter out artifacts if desired by running the list through
Buildr.artifacts() and filtering based on "artifactness" (i.e., elements
that respond to :to_spec / :to_spec_hash)
Also: Do I really have to take the ugly way of generating a temporary
pom.xml on the file system rather than using the XML builder to generate a
string which can then be used as the pom content? For some reason
"package(:jar).pom.content('...pom content...')" does not seem to work as
expected....
Not that should not be necessary. If you want to post code illustrating a
case that doesn't work, I'll be happy to review it.
(Of course closing issue BUILDR-486 would be even better... :)
Agreed. It's high on my list but I'm in the last leg of a project crunch at
work so it will have to wait a little bit.
alex
