buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Boisvert <>
Subject Re: Problems with dependent projects
Date Mon, 01 Aug 2011 18:28:53 GMT
On Mon, Aug 1, 2011 at 10:50 AM, Matteo Vaccari <> wrote:

> My feeling is that it should work like this:
> > define 'problematic' do
> >   define 'foo' do
> >     package :war
> >   end
> >
> >   define 'bar' do
> >     compile.with project('foo')
> >   end
> > end
> This works OK in eclipse, as it lets bar use both src and test from
> foo.  It fails in compilation though.  I would say that the problem is
> in the compile task.

I understand where you're coming from but we have to make sure the rules are
straight and simple;  I don't want this sort of thing to be magical
otherwise things quickly become unwieldy.

compile.with is currently defined as,

    # :call-seq:
    #   with(*artifacts) => self
    # Adds files and artifacts as dependencies, and returns self.
    # Calls #artifacts on the arguments, so you can pass artifact
    # tasks, projects, etc. Use this rather than setting the dependencies
array directly.
    # For example:
    #   compile.with('module1.jar', 'log4j:log4j:jar:1.0', project('foo'))
    def with(*specs)
      @dependencies |= Buildr.artifacts(specs.flatten).uniq

So when you reference project('foo') in compile.with, you get foo's
published artifacts -- basically today foo decides what gets exported.

Ignoring backward compatibility for a second, I'd be OK to changing
compile.with such that any referenced project is mapped to both its and  (And for consistency, we would use
the same rule for test.with, run.with and similar functions.)   However, if
you'd want to use foo's jar then you'd need to write compile.with
project('foo').package(:jar) instead.     But I wouldn't want to get into
rules that look like "if foo exports a jar, use it, otherwise use its, yaddy-yadda."  It's too much to require our users to
remember these rules and they could easily get confused.

I think this change would align us better which today's IDE defaults and
people's initial expectations.  So my only restraint is that we would need
to roll this out in a backward-compatibility-breaking major release.  It
couldn't go in a minor release.

Thoughts from the peanut gallery?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message