buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Boisvert <alex.boisv...@gmail.com>
Subject Re: Problem using build.yaml to specify groups of dependencies
Date Fri, 11 Nov 2011 21:57:02 GMT
I've committed a fix on trunk for this.  Any chance you can try it?

"rake gem" will create local gems for you to install.

alex

On Fri, Nov 11, 2011 at 5:51 PM, Russ Teabeault <rteabeault@rallydev.com>wrote:

> Thanks for taking a look at this Alex.  I tried adding your suggestion and
> it almost works but I think there might be another bug here.  The problem
> is with specs that have a classifier.  For example,
> consider net.sf.json-lib:json-lib:jar:jdk15:2.3 which has the 'jdk15'
> classifier.  When this is listed under my compile dependencies it ends up
> raising the error "RuntimeError : Expecting a String, Hash or object that
> responds to to_spec"  After looking at the code I see the following:
>
> When the build.yaml is loaded the ArtifactNamespace.use method determines
> that compile is a group and sets is_group to true.  It then adds the each
> artifact in the group to the registry using the unversioned spec string
> "net.sf.json-lib:json-lib:jar:jdk15".  It then calls the group method
> passing in 'compile' and all the spec names.  The group method creates a
> lambda that when called will do a values_at using the spec names.  The
> values_at method then generates a key
> using ArtifactRequirement.unversioned_spec(name).  But name here is
> "net.sf.json-lib:json-lib:jar:jdk15" and so the key comes out
> as "net.sf.json-lib:json-lib:jar".  So when it calls get on the registry
> using this key it returns false since the registry is using
> ""net.sf.json-lib:json-lib:jar:jdk15" key.  And 'false' is passed to the
> satisfied_by method which ends up throwing the error.
>
> So in short it seems that unversioned_spec is called twice on the spec
> name.  The first call leaves the spec name with the classifier dangling off
> the end.  This is used as the key to the registry. The second call, used to
> find the artifact in the registry ends up chopping the classifier off
> because it thinks it is the version.
>
> Thoughts?
>
> Thanks,
> -russ
>
> On Fri, Nov 11, 2011 at 4:56 AM, Alex Boisvert <alex.boisvert@gmail.com
> >wrote:
>
> > On Thu, Nov 10, 2011 at 7:26 PM, Russ Teabeault <rteabeault@rallydev.com
> > >wrote:
> >
> > > I am trying to use buildr.yaml to specify my dependencies
> > >
> > > artifacts:
> > >  compile:
> > >    - ant:ant:jar:1.6.5
> > >    - ant-contrib:ant-contrib:jar:1.0b2
> > >    - ...
> > >
> > > Based on everything I have read I should then be able to do
> > >
> > > compile.with artifact_ns[:compile]
> > >
> > > However, this fails in the artifacts method of artifact.rb since each
> > spec
> > > in the array is an ArtifactRequirement and there is no case handling
> that
> > > type.
> > >
> > > Is this a bug?  Is there a better way to do this?  What are other
> people
> > > doing?
> > >
> >
> > Yes, that is a bug.  artifacts() doesn't correctly handle objects that
> > ActsLikeArtifact. Will be fixed in trunk in a few minutes.
> >
> > In the mean time or for previous versions, you can write,
> >
> > compile.with artifact_ns.compile.map(&:artifact)
> >
> > instead.
> >
> > alex
> >
>

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