Mathias, Feel free to open issues on github, I'll be happy to discuss it with you. The problem I have now is that my use cases of the extension are limited, I just want transitive dependencies and pom generation. I want more people to start using the extension and tell me what gaps they'd like to fill to make the transition to Buildr easier.
-JS On Mon, Jan 17, 2011 at 6:14 AM, Mathias <[email protected]> wrote: > 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 > > > >
