> 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
