buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Shahid <jvsha...@gmail.com>
Subject Re: Specify custom POM for uploading
Date Mon, 17 Jan 2011 01:49:14 GMT
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
>
> ---
> 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