On 10 Feb 2010, at 20:11, Antoine Toulme wrote: > Apologies. So we're talking existing Buildr code with a bug. I thought your > extension was doing this. No worries. I understand your response better now.
> Can you please file a bug ? I don't have much free time but I can try > creating a spec that reproduces the problem. Will do. I mainly asked the question because I was curious how this should be fixed. It seemed that the intention was to support different implementations of install/uninstall per package type, but this did not work in practice. The reproduction case is as simple as the build script I posted. I'll add that to the bug report. Pepijn > > 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 >>>> >>>> >>>>
