buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Toulme <anto...@lunar-ocean.com>
Subject Re: Extending Buildr optionally
Date Tue, 24 Feb 2009 18:25:57 GMT
OK, we did something along those lines.

Thanks!

Antoine

On Mon, Feb 23, 2009 at 4:45 PM, Assaf Arkin <arkin@intalio.com> wrote:

> On Mon, Feb 23, 2009 at 3:03 AM, Antoine Toulme <antoine@lunar-ocean.com>wrote:
>
>> Hi,
>>
>> I am working on extending the Buildr::Project class so that a project can
>> represent an Eclipse feature. We also have the same work to do to make the
>> project represent a plugin.
>> Those two natures are mutually exclusive, and both add a lot to the
>> Buildr::Project class already.
>>
>> I thought of adding a mechanism for projects to explicitly set their
>> nature.
>>
>> module Buildr4Eclipse
>> >   module ProjectNature
>> >     include Buildr::Extension
>> >
>> >     attr_accessor :nature
>> >
>> >     # Returns true if the project has the specific nature
>> >     def has_nature(n)
>> >       ...
>> >     end
>> >   end
>> > end
>> >
>> > class Buildr::Project
>> >   include Buildr4Eclipse::ProjectNature
>> > end
>>
>>
>> Then I added a hook for the feature:
>>
>> module Buildr4Eclipse
>> > # A hook to add dynamically the feature methods and attributes to
>> projects
>> > that have the :feature nature
>> >   module FeatureProjectHook
>> >       include Buildr::Extension
>> >       before_define do |project|
>> >         project.extend Buildr4Eclipse::FeatureProject  if
>> > (project.has_nature("feature"))
>> >       end
>> >   end
>> > end
>> >
>> > class Buildr::Project
>> >   include Buildr4Eclipse::FeatureProjectHook
>> > end
>>
>>
>> My test units show that it worked but I was a bit suspicious. The define
>> method is not evaluated in the same way in test units.
>>
>> Indeed, now this works:
>>
>> > define('foo', :nature => "feature") do |project|
>> >   project.feature_xml
>> > end
>>
>>
>>  But this fails:
>>
>> > define('foo') do |project|
>> >   project.nature = "feature"
>> >   project.feature_xml
>> > end
>> >
>>
>> I am not sure at this point whether this happens because of the
>> manipulation
>> that is made on the define method to make it execute correctly during
>> tests,
>> if it is expected, or if I should not push further because it is too
>> hacky.
>
>
> before_define executes before the definition. In the first case nature is
> set, and the definition can use it. In the second example nature is not set
> until you reach the definition.
>
>
>>
>>
>> I also might be missing something obvious as to how set the project
>> nature.
>
>
> Ideally nature should report to you what the nature of the project is. But
> you don't want to make all these side effects happen as a result of setting
> a property. You want to do something in the project, and have its nature set
> as a side-effect of that. Something like:
>
> define 'my_feature' do |project|
>   act_as_eclipse_feature
> end
>
> p project('my_feature').nature
> => 'feature'
>
> Assaf
>
>
>>
>> Maybe there's something equivalent in Buildr I missed ?
>>
>> Thanks!
>>
>> Antoine
>>
>
>

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