buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russ Teabeault <rteabea...@rallydev.com>
Subject Re: Problem using build.yaml to specify groups of dependencies
Date Fri, 11 Nov 2011 22:17:31 GMT
I will give it a try.  It I cant get it done today I will on Monday and
will report back.  Thanks!

-russ

On Fri, Nov 11, 2011 at 2:57 PM, Alex Boisvert <alex.boisvert@gmail.com>wrote:

> 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