I can either take some sleep time to do it or get to it in 2 to 3 weeks. So feel free...
On Wed, Feb 10, 2010 at 14:28, Alex Boisvert <[email protected]>wrote: > I think the absence of tests/spec for package(:gem) is catching up to us. > If Antoine doesn't get to it before, I'll take a look this weekend. > > alex > > > > On Wed, Feb 10, 2010 at 2:02 PM, Antoine Toulme > <[email protected]>wrote: > >> Thanks Pepjin, sorry for the confusion. I'll try following up on the bug - >> I'm not a Buildr committer but I can probably find a fix. >> >> On Wed, Feb 10, 2010 at 11:34, Pepijn Van Eeckhoudt < >> [email protected]> wrote: >> >> > >> > 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 >> > >>>> >> > >>>> >> > >>>> >> > >> > >> > >
