buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Toulme <anto...@lunar-ocean.com>
Subject Re: PackageGemTask methods not called
Date Thu, 11 Feb 2010 00:03:00 GMT
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 <antoine@lunar-ocean.com>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 <alex.boisvert@gmail.com>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 <antoine@lunar-ocean.com>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 <
>>> pepijn.vaneeckhoudt@luciad.com> 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 <
>>> > > pepijn.vaneeckhoudt@luciad.com> 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 <
>>> antoine@lunar-ocean.com>
>>> > 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 <
>>> > >>> pepijn.vaneeckhoudt@luciad.com> 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<
>>> > >>>>> pepijn@vaneeckhoudt.net
>>> > >>>>>
>>> > >>>>> 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 | pepijn.vaneeckhoudt@luciad.com
>>> > >>>>
>>> > >>>> LUCIAD - high performance visualization
>>> > >>>> Wetenschapspark Arenberg | Gaston Geenslaan 9
>>> > >>>> 3001 Leuven | Belgium | www.luciad.com
>>> > >>>>
>>> > >>>>
>>> > >>>>
>>> >
>>> >
>>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message