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 <[email protected]>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 <[email protected] > >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 <[email protected] > > >wrote: > > > > > On Thu, Nov 10, 2011 at 7:26 PM, Russ Teabeault < > [email protected] > > > >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 > > > > > >
