I have a stupid question about this stuff though. Do we want to support the Maven behavior, the gemcutter behavior, or both ? Because it looks like we would have to choose between the two right now. I see interest in both.
Second thing that comes to mind: could we try using a gem repository the same way we use a Maven one ? In that case javagems for example would make sense. >From the release_to repository, Buildr would know how to do the upload/install for gems, and there will be less ambiguity for this case. Just throwing ideas. On Wed, Feb 10, 2010 at 14:30, Antoine Toulme <[email protected]>wrote: > 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 >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>> > >>> >> >> >
