buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <ar...@intalio.com>
Subject Re: Extending Buildr optionally
Date Mon, 23 Feb 2009 15:45:04 GMT
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