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 15:03:18 GMT
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 <mathias@parboiled.org> 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
>
> ---
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message