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 Mon, 17 Jan 2011 11:14:15 GMT
John,

this look good!
I will try out your plugin ASAP.

One thing: I think it would be nice to allow for the easy inclusion of additional, custom
POM elements (like licenses or repositories).
But even without that this looks like a really useful addition to the Buildr universe

Cheers,
Mathias

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

On 17.01.2011, at 02:49, John Shahid wrote:

> 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