You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@buildr.apache.org by Pepijn Van Eeckhoudt <pe...@luciad.com> on 2010/03/03 16:47:51 UTC
Ant tasks version handling
I'm bumping in to a general problem with ant task versions, but I'll use
cobertura as a concrete example.
The cobertura extension lists its dependencies as
@dependencies ||= [
"net.sourceforge.cobertura:cobertura:jar:#{version}",
"log4j:log4j:jar:1.2.9",
"asm:asm:jar:2.2.1",
"asm:asm-tree:jar:2.2.1", "oro:oro:jar:2.0.8"]
version can be modified via build.yml, but if you actually do this (e.g.
update to cobertura 1.9.4) the dependencies list is no longer correct
since cobertura 1.9.4 requires asm 3.0.
The simple way to correct this would be to replace the dependencies with
@dependencies ||= Buildr.transitive(
"net.sourceforge.cobertura:cobertura:jar:#{version}" )
but then you end up including ant 1.7.0 since it is listed in coberturas
pom file.
I guess it's simple enough to just reject org.apache.ant* from the
transitive list, but due to the way transitive works, buildr is going to
try to download the ant 1.7.0 pom anyway (see POM.dependencies). I'm
using an internal repository instead of maven central and ant 1.7.0 is
not available there so this fails and this in turns causes the entire
build to fail.
Long story short, I think it would be useful to extend transitive with a
means to eagerly filter out dependencies (perhaps via a block?). This
would have to be passed on to POM.dependencies as well to get everything
working correctly. Does this sound like a useful addition or is there a
better way to tackle this?
Pepijn
Re: Ant tasks version handling
Posted by Alex Boisvert <al...@gmail.com>.
On Thu, Mar 4, 2010 at 4:29 AM, Pepijn Van Eeckhoudt <
pepijn.vaneeckhoudt@luciad.com> wrote:
> On 3/3/2010 20:07, Alex Boisvert wrote:
>
>> I've started migrating all these artifact requirements to use
>> artifact_ns()
>> such that they are easier to configure, through buildr.yaml or
>> programmatically without monkey-patching. When you run into code that
>> doesn't use artifact_ns(), please open an issue so we clean it up.
>>
> The artifact_ns approach seems like a nice way to resolve this. I made an
> issue with an attached patch for the cobertura extension. If you could
> review this I can spend some time to migrate other extensions in the same
> fashion.
>
Yes, it looked good. Thanks for your help!
alex
Re: Ant tasks version handling
Posted by Pepijn Van Eeckhoudt <pe...@luciad.com>.
On 3/3/2010 20:07, Alex Boisvert wrote:
> I've started migrating all these artifact requirements to use artifact_ns()
> such that they are easier to configure, through buildr.yaml or
> programmatically without monkey-patching. When you run into code that
> doesn't use artifact_ns(), please open an issue so we clean it up.
The artifact_ns approach seems like a nice way to resolve this. I made
an issue with an attached patch for the cobertura extension. If you
could review this I can spend some time to migrate other extensions in
the same fashion.
Pepijn
Re: Ant tasks version handling
Posted by Alex Boisvert <al...@gmail.com>.
On Wed, Mar 3, 2010 at 10:43 AM, Pepijn Van Eeckhoudt <
pepijn.vaneeckhoudt@luciad.com> wrote:
>
>
> Op 3-mrt-2010 om 18:56 heeft Alex Boisvert <al...@gmail.com> het
> volgende geschreven:\
>
>
>> Personally, I would not use transitive() here at runtime. I would run
>> transitive() to obtain the list of new dependencies and explicitly set the
>> manually-corrected list,
>>
>> @dependencies ||= [ "net.sourceforge.cobertura:cobertura:jar:1.9.4",
>> "log4j:log4j:jar:1.2.9",
>> "asm:asm:jar:3.0", "asm:asm-tree:jar:2.2.1", "oro:oro:jar:2.0.8"]
>>
> The issue I have with this is that it pins you to a specifc version. The
> version method provides a mechanism to specify the cobertura version in the
> build.yml, however this doesn't work in practice. In other words if you need
> a bugfix release of cobertura (which is what caused us to hit this problem)
> you either have to monkey-patch the extension or create a new buildr
> release. Neither seem like good solutions...
Monkey-patching is probably the "best" solution right now.
I've started migrating all these artifact requirements to use artifact_ns()
such that they are easier to configure, through buildr.yaml or
programmatically without monkey-patching. When you run into code that
doesn't use artifact_ns(), please open an issue so we clean it up.
Independently of the above, I think this would be a worthwhile improvement
> to transitive() ... I think somebody else (Chetan?) had the same need just
> a
> week ago. My only warning is that it's a slippery slope from there... you
> get into version number comparison issues quickly and there's little
> consistency there, or you want to exclude dependencies of another
> dependency, ... things like that.
>
What I had in mind was an optional block that takes the artifact spec as
> parameter and returns boolean. A simple artifact filter in other words. This
> would then be checked as the dependency graph is traversed, cutting off the
> recursion when false is returned. How the filtering happens is undefined so
> this would basically push version comparison stuff to the user of the api ;)
> Do you think it makes sense to pass the dependency stack instead of only a
> single spec?
>
Yes, or both ancestors and spec separately.
alex
Re: Ant tasks version handling
Posted by Pepijn Van Eeckhoudt <pe...@luciad.com>.
Op 3-mrt-2010 om 18:56 heeft Alex Boisvert <al...@gmail.com>
het volgende geschreven:\
>
> Personally, I would not use transitive() here at runtime. I would
> run
> transitive() to obtain the list of new dependencies and explicitly
> set the
> manually-corrected list,
>
> @dependencies ||= [ "net.sourceforge.cobertura:cobertura:jar:1.9.4",
> "log4j:log4j:jar:1.2.9",
> "asm:asm:jar:3.0", "asm:asm-tree:jar:2.2.1", "oro:oro:jar:2.0.8"]
The issue I have with this is that it pins you to a specifc version.
The version method provides a mechanism to specify the cobertura
version in the build.yml, however this doesn't work in practice. In
other words if you need a bugfix release of cobertura (which is what
caused us to hit this problem) you either have to monkey-patch the
extension or create a new buildr release. Neither seem like good
solutions...
> Independently of the above, I think this would be a worthwhile
> improvement
> to transitive() ... I think somebody else (Chetan?) had the same
> need just a
> week ago. My only warning is that it's a slippery slope from
> there... you
> get into version number comparison issues quickly and there's little
> consistency there, or you want to exclude dependencies of another
> dependency, ... things like that.
What I had in mind was an optional block that takes the artifact spec
as parameter and returns boolean. A simple artifact filter in other
words. This would then be checked as the dependency graph is
traversed, cutting off the recursion when false is returned. How the
filtering happens is undefined so this would basically push version
comparison stuff to the user of the api ;) Do you think it makes sense
to pass the dependency stack instead of only a single spec?
Pepijn
Re: Ant tasks version handling
Posted by Alex Boisvert <al...@gmail.com>.
On Wed, Mar 3, 2010 at 7:47 AM, Pepijn Van Eeckhoudt <
pepijn.vaneeckhoudt@luciad.com> wrote:
> I'm bumping in to a general problem with ant task versions, but I'll use
> cobertura as a concrete example.
>
> The cobertura extension lists its dependencies as
> @dependencies ||= [ "net.sourceforge.cobertura:cobertura:jar:#{version}",
> "log4j:log4j:jar:1.2.9",
> "asm:asm:jar:2.2.1", "asm:asm-tree:jar:2.2.1",
> "oro:oro:jar:2.0.8"]
>
> version can be modified via build.yml, but if you actually do this (e.g.
> update to cobertura 1.9.4) the dependencies list is no longer correct since
> cobertura 1.9.4 requires asm 3.0.
>
> The simple way to correct this would be to replace the dependencies with
> @dependencies ||= Buildr.transitive(
> "net.sourceforge.cobertura:cobertura:jar:#{version}" )
>
Personally, I would not use transitive() here at runtime. I would run
transitive() to obtain the list of new dependencies and explicitly set the
manually-corrected list,
@dependencies ||= [ "net.sourceforge.cobertura:cobertura:jar:1.9.4",
"log4j:log4j:jar:1.2.9",
"asm:asm:jar:3.0", "asm:asm-tree:jar:2.2.1", "oro:oro:jar:2.0.8"]
> Long story short, I think it would be useful to extend transitive with a
> means to eagerly filter out dependencies (perhaps via a block?). This would
> have to be passed on to POM.dependencies as well to get everything working
> correctly. Does this sound like a useful addition or is there a better way
> to tackle this?
>
Independently of the above, I think this would be a worthwhile improvement
to transitive() ... I think somebody else (Chetan?) had the same need just a
week ago. My only warning is that it's a slippery slope from there... you
get into version number comparison issues quickly and there's little
consistency there, or you want to exclude dependencies of another
dependency, ... things like that.
alex