Apologies. So we're talking existing Buildr code with a bug. I thought your extension was doing this.
Can you please file a bug ? I don't have much free time but I can try creating a spec that reproduces the problem. On Wed, Feb 10, 2010 at 11:04, Pepijn Van Eeckhoudt < [email protected]> wrote: > It's not me that's pushing the limits. This gem support is part of Buildr > 1.3.5 (see gems.rb). > > Could you do something like super.install if super.respond_to? :install > Or does that not make any sense? > > Pepijn > > Op 10-feb-2010 om 18:45 heeft Antoine Toulme <[email protected]> het > volgende geschreven:\ > > > I see, it makes sense. >> >> Well, obviously you are trying to push Buildr a bit by trying to use it >> for >> non-Maven repository uses. >> >> Here are the options I can think of: >> -use a different task name to push gems >> -extend the upload/install tasks by enhancing them - the gem will still be >> deployed in the maven repo, plus where you want to push it. >> -maybe create a module like ActAsArtifact and extend the task in a >> after_define block ? That might work. >> >> On Wed, Feb 10, 2010 at 09:35, Pepijn Van Eeckhoudt < >> [email protected]> wrote: >> >> Hi Antoine, >>> >>> Rereadig my mail, I realize that I should have provided a bit more >>> context >>> (and sorry for the double message BTW). >>> >>> My buildfile essentially contains something like this: >>> >>> define 'my-extension' do >>> package(:gem) >>> end >>> >>> package will call pacakge_as_gem which in turn will create a >>> PackageGemTask. PackageGemTask has it's own install/uninstall/upload >>> implementations. package then takes the PackageGemTask instance and >>> extends >>> it with ActsAsArtifact which overrides install/uninstall/upload from >>> PackageGemTask. The net effect of this is that PackageGemTask#install is >>> never called. >>> >>> Given that observation I was wondering how to fix this and if it is >>> possible in the first place. In other words, it is possible for a package >>> to >>> provide it's own versions of the methods defined in ActsAsArtifact. >>> >>> Regards, >>> >>> Pepijn >>> >>> >>> On 10/2/2010 18:15, Antoine Toulme wrote: >>> >>> Hi Pepjin, >>>> >>>> to package a buildr extension you typically don't need to use Buildr >>>> itself. >>>> You can create a .gemspec file, then do: >>>> >>>> gem build gem.gemspec >>>> gem push gem-1.0.gem >>>> >>>> I might be missing something, but really the line you point at is not >>>> related to gem building and is very important in Buildr - it helps >>>> Buildr >>>> know how to handle packages as artifacts, so where to upload them for >>>> example. >>>> >>>> Thanks, >>>> >>>> Antoine >>>> >>>> >>>> On Wed, Feb 10, 2010 at 01:54, Pepijn Van Eeckhoudt< >>>> [email protected] >>>> >>>> wrote: >>>>> >>>>> >>>> Hi, >>>> >>>>> >>>>> I'm trying to package a buildr extension as a gem so I can distribute >>>>> it >>>>> more easily. It seems the PackageGemTask#install method is never called >>>>> though. >>>>> >>>>> I'm kind of new to Ruby so I'm not 100% sure what's going on, but I >>>>> think >>>>> line 173 in buildr/packaging/package.rb ('package.extend >>>>> ActsAsArtifact') >>>>> is >>>>> to blame. By extending the package object with ActsAsArtifact, the >>>>> install, >>>>> uninstall and upload methods get overridden and so the Gem specific >>>>> variants >>>>> are never invoked. >>>>> >>>>> I would like to patch this, but I'm not sure what would be the best way >>>>> would be to resolve this? Is there some Ruby idiom that would allow >>>>> this? >>>>> >>>>> Regards, >>>>> >>>>> Pepijn Van Eeckhoudt >>>>> >>>>> >>>>> >>>> >>> -- >>> Pepijn Van Eeckhoudt - Project Leader >>> T +32 16 23 95 91 >>> F +32 16 29 34 22 | [email protected] >>> >>> LUCIAD - high performance visualization >>> Wetenschapspark Arenberg | Gaston Geenslaan 9 >>> 3001 Leuven | Belgium | www.luciad.com >>> >>> >>>
