I like this approach better as well... Seems very natural.
Wayne
On 3/21/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
Hey, this occurred to me last night...
Why not have one goal, enforcer:enforce, then abstract the things to
enforce into rules...
public interface EnforcementRule {
void execute();
}
And then configure...
<plugin>
<groupId>...
<artifactId>...
<configuration>
<rules>
<requireJavaVersion>
<version>[1.3,1.6]</version>
</requireJavaVersion>
<requireMavenVersion>
<version>[2.0.5)</version>
</requireMavenVersion>
</rules>
</configuration>
</plugin>
IIUC if have 'EnforcementRule[] rules;' in your mojo and you define
impls of EnforcementRule like RequireJavaVersion and
RequireMavenVersion in the same package, then plexus should inject
the instances of the right class into the array.
Then the mojo is really simple, can execute any kind of rules from
it... and folks can use the implementation="" stuff to inject their
own rules too if needed. Then the goal basically executes the rules
and then based on if they pass/fail do something about it (fail the
build, warn, etc.).
--jason
On Mar 20, 2007, at 4:19 PM, Brian E. Fox wrote:
>
>
>
>> Personally I have not problem adding extra execution per thing
>> I want to enforce. IMO that is much clearer and simplifies
>> the implementing mojo.
>
> Potentially yes, but it's also a performance issue invoking the plugin
> extra times. In my situation, I have about 100+ modules that would be
> doing this. If I can figure out how to make it execute only once per
> execution no matter where the build is started, then I think
> separating
> them is logical. In fact, if this is possible, I think it's a
> requirement.
>
>
>> Funny... most folks I know don't use version ranges. We
>> (geronimo) tried to use them at one point for our specs, but
>> key plugins (like the idea plugin) don't support it.
>
>> I don't think that most folks using M2 are familiar with
>> ranges... nor do they use them... and when those who do use
>> them... usually tend to find out they don't work so well.
>
> Fair enough. I think I discovered why they don't work in many cases
> while trying to use them.
>
>> The OS stuff falls into the same boat, why reinvent a syntax when one
>> already exists?
>
>> Ya, I hear ya... it was just a comment... and more about how
>> the range syntax hurts my brain more than anything ;-) Just
>> looking at a range its not really easy to tell what it
>> means... where IMO the 1.0+ and 1.0* syntax is relatively
>> clear w/o having to go read a syntax mapping table ;-)
>
> Although I am not a fan of the implementation, the syntax is logical
> once you understand it. Not entirely covering all scenarios, but
> certainly enough for this. I don't think the 1.0+, 1.0* is enough to
> handle all cases.
>
> Consider 2.1. Perhaps there is a regression in backwards compatibility
> in the first build. Someone may want to say 2.0.6 < x < 2.1 || x > 2.1
> (in otherwords greater than 2.0.6 but not 2.1.0. You can do this with
> the current specification. I'm not sure that any expression
> language is
> going to be completely natural and support enough use cases... If
> that's
> true, then this one is as good as any. I could be convinced otherwise
> though if there are some alternatives that can be pointed out.
>
> Does anyone else have an opinion?
>
> (btw, I anticipated exactly this disussion, which is why I put out the
> RFC)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
