buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathias <math...@parboiled.org>
Subject Re: Specify custom POM for uploading
Date Fri, 14 Jan 2011 15:10:53 GMT
> 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

---
mathias@parboiled.org
http://www.parboiled.org

On 13.01.2011, at 18:44, Alex Boisvert wrote:

> On Thu, Jan 13, 2011 at 1:14 AM, Mathias <mathias@parboiled.org> 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


Mime
View raw message