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 --- [email protected] 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 >> >> --- >> [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 >
