So I checked out head and the classifier problem is fixed. I was able to do
compile.with artifact_ns.compile Should I also be able to do compile.with artifacts(:compile) ? Thanks, -russ On Fri, Nov 11, 2011 at 3:17 PM, Russ Teabeault <rteabea...@rallydev.com>wrote: > 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.boisv...@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 <rteabea...@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.boisv...@gmail.com >> > >wrote: >> > >> > > On Thu, Nov 10, 2011 at 7:26 PM, Russ Teabeault < >> rteabea...@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 >> > > >> > >> > >
