You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Brian E. Fox" <br...@reply.infinity.nu> on 2007/03/20 05:04:55 UTC
maven-enforcer-plugin
There is a new plugin that I'd like to get some feedback on,
particularly on non-windows os's and the unit tests.
The maven-enforcer-plugin picks up where <prerequisites> leaves off and
allows control over the maven, jdk and os versions of a build.
This plugin was initially conceived here:
http://www.nabble.com/Control-of-maven-using-prerequisites-tf3231437s177
.html#a8979318
And here:
http://www.nabble.com/Why-is-prerequisites-not-inherited--tf3236197s177.
html#a9016296
1.0-alpha-1-SNAPSHOT is deployed and the site is here:
http://maven.apache.org/plugins/maven-enforcer-plugin/ (just deployed so
give it a little bit to completely update)
If all goes well and no major issues are uncovered, then I think it's
ready for staging and a vote.
Thanks,
Brian
Re: maven-enforcer-plugin
Posted by Jason Dillon <ja...@planet57.com>.
Just throwing this out there... but why not just use Jexl to allow
expression like "mavenVersion == 1.2" to be evaluated? I just saw
the table of range to meaning and this just popped into my head...
like why do you need some extra syntax when you could just evaluate
an expression?
--jason
On Mar 19, 2007, at 9:04 PM, Brian E. Fox wrote:
> There is a new plugin that I'd like to get some feedback on,
> particularly on non-windows os's and the unit tests.
>
>
>
> The maven-enforcer-plugin picks up where <prerequisites> leaves off
> and
> allows control over the maven, jdk and os versions of a build.
>
>
>
> This plugin was initially conceived here:
>
> http://www.nabble.com/Control-of-maven-using-prerequisites-
> tf3231437s177
> .html#a8979318
>
> And here:
>
> http://www.nabble.com/Why-is-prerequisites-not-inherited--
> tf3236197s177.
> html#a9016296
>
>
>
> 1.0-alpha-1-SNAPSHOT is deployed and the site is here:
> http://maven.apache.org/plugins/maven-enforcer-plugin/ (just
> deployed so
> give it a little bit to completely update)
>
>
>
> If all goes well and no major issues are uncovered, then I think it's
> ready for staging and a vote.
>
>
>
> Thanks,
>
> Brian
>
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-enforcer-plugin
Posted by Jason Dillon <ja...@planet57.com>.
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.
Performance problem a? Sounds like a problem with mvn if its a bit
overhead to invoke 2 executions of the same plugin. But I got your
point.
>> 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.
I agree... if the range stuff works, then it does cover much more
scenarios... I still don't like it, but c'est la vie ;-)
--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: maven-enforcer-plugin
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Yes, me too.
-----Original Message-----
From: Wayne Fay [mailto:waynefay@gmail.com]
Sent: Wednesday, March 21, 2007 2:20 PM
To: Maven Developers List
Subject: Re: maven-enforcer-plugin
I like this approach better as well... Seems very natural.
Wayne
On 3/21/07, Jason Dillon <ja...@planet57.com> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-enforcer-plugin
Posted by Wayne Fay <wa...@gmail.com>.
I like this approach better as well... Seems very natural.
Wayne
On 3/21/07, Jason Dillon <ja...@planet57.com> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-enforcer-plugin
Posted by Jason Dillon <ja...@planet57.com>.
My guess is that the EnforcementRule interface might need to allow
some context to be passed in, since its not really easy to get
@component or @parameter expression="" stuff into a child config
object IIRC. Also, probably should throw Exception, to free the rule
from having to worry about catch/retrhow muck. All that can be done
by the mojo, which will simplify the rule impls.
--jason
On Mar 21, 2007, at 2:35 PM, Andrew Williams wrote:
> Much better - properly extensible too :)
>
> Andy
>
> On 21 Mar 2007, at 18:13, Jason Dillon 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-enforcer-plugin
Posted by Andrew Williams <an...@handyande.co.uk>.
Much better - properly extensible too :)
Andy
On 21 Mar 2007, at 18:13, Jason Dillon 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-enforcer-plugin
Posted by Shane Isbell <sh...@gmail.com>.
Hi Jason,
The general approach sounds good. A large part of the NMaven project deals
with matching of platform capabilities. The pattern includes:
public interface ExecutableMatchPolicy
{
/**
* Returns true if <code>ExecutableCapability</code> matches the policy
implementation, otherwise returns false.
*
* @param executableCapability the executable capability to match
* @return true if <code>ExecutableCapability</code> matches the policy
implementation, otherwise returns false.
*/
boolean match( ExecutableCapability executableCapability );
}
with an implementation like this within a Factory class. This one matches
version.
/**
* Creates a policy to match the framework version
*
* @param frameworkVersion
* @return a policy to match the framework version
*/
static ExecutableMatchPolicy createFrameworkVersionPolicy( final String
frameworkVersion )
{
return new ExecutableMatchPolicy()
{
public boolean match( ExecutableCapability executableCapability
)
{
for ( String fv : executableCapability.getFrameworkVersions()
)
{
if ( frameworkVersion.toLowerCase().trim().equals(
fv.trim() ) )
{
return true;
}
}
return false;
}
};
}
Next, a class that contains iterating over a list of match policies, meaning
all policies must be true for a match:
private boolean matchExecutableCapability( ExecutableCapability
executableCapability,
List<ExecutableMatchPolicy>
matchPolicies )
{
for ( ExecutableMatchPolicy executableMatchPolicy : matchPolicies )
{
boolean match = executableMatchPolicy.match(
executableCapability );
if ( !match )
{
return false;
}
}
return true;
}
Hope this help,
Shane
On 3/21/07, Jason Dillon <ja...@planet57.com> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
Re: maven-enforcer-plugin
Posted by Jason Dillon <ja...@planet57.com>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
RE: maven-enforcer-plugin
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-enforcer-plugin
Posted by Jason Dillon <ja...@planet57.com>.
On Mar 20, 2007, at 5:14 AM, Brian E. Fox wrote:
> Come, on - enforcer:enforce just sounds cool.
Ya, but its not terribly descriptive :-P
> I actually started in this direction, and the code to check both
> versions was nearly identical. After I thought about it for a while, I
> thought that these two where likely to be used very frequently
> together.
> Instead of forcing someone to bind the plugin to two executions, it
> made
> sense to combine them into a single goal. OS was different enough that
> it belongs separate.
Personally I have not problem adding extra execution per thing I want
to enforce. IMO that is much clearer and simplifies the implementing
mojo.
> If you feel strongly enough about the name, I'm not particularly
> tied to
> it...just like the way it sounds.
>
> For the version range syntax, I put some thought into this one. I
> decided that good or bad, someone using Maven would more likely be
> familiar with the current range syntax than something else. This
> turned
> out to be a major PITA because it didn't work right out of the box due
> to various implementation quirks. I'm open to other solutions, but I
> still maintain that consistency is best for the users so they don't
> have
> to learn multiple range specifications. I know that there is a
> proposal
> out there to replace the range handling in maven, and I would expect
> this plugin to be updated to handle new specifications as well to
> match
> maven.
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.
> 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 ;-)
--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: maven-enforcer-plugin
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Come, on - enforcer:enforce just sounds cool.
I actually started in this direction, and the code to check both
versions was nearly identical. After I thought about it for a while, I
thought that these two where likely to be used very frequently together.
Instead of forcing someone to bind the plugin to two executions, it made
sense to combine them into a single goal. OS was different enough that
it belongs separate.
If you feel strongly enough about the name, I'm not particularly tied to
it...just like the way it sounds.
For the version range syntax, I put some thought into this one. I
decided that good or bad, someone using Maven would more likely be
familiar with the current range syntax than something else. This turned
out to be a major PITA because it didn't work right out of the box due
to various implementation quirks. I'm open to other solutions, but I
still maintain that consistency is best for the users so they don't have
to learn multiple range specifications. I know that there is a proposal
out there to replace the range handling in maven, and I would expect
this plugin to be updated to handle new specifications as well to match
maven.
The OS stuff falls into the same boat, why reinvent a syntax when one
already exists?
-----Original Message-----
From: Jason Dillon [mailto:jason.dillon@gmail.com] On Behalf Of Jason
Dillon
Sent: Tuesday, March 20, 2007 12:14 AM
To: Maven Developers List
Subject: Re: maven-enforcer-plugin
Seems a wee bit odd that you have "enforcer:enforce" which handles
maven version and java version, then "enforcer:os" which handles os
stuff. I'd rather have enforcer:require-maven, enforcer:require-
java, enforcer:require-os, *
I'm also not keen on the version range muck... but I guess its more
flexible that the 1.0+ and 1.0* stuff I was using. Still though the
version range specification never really felt natural to me ;-)
--jason
On Mar 19, 2007, at 9:04 PM, Brian E. Fox wrote:
> There is a new plugin that I'd like to get some feedback on,
> particularly on non-windows os's and the unit tests.
>
>
>
> The maven-enforcer-plugin picks up where <prerequisites> leaves off
> and
> allows control over the maven, jdk and os versions of a build.
>
>
>
> This plugin was initially conceived here:
>
> http://www.nabble.com/Control-of-maven-using-prerequisites-
> tf3231437s177
> .html#a8979318
>
> And here:
>
> http://www.nabble.com/Why-is-prerequisites-not-inherited--
> tf3236197s177.
> html#a9016296
>
>
>
> 1.0-alpha-1-SNAPSHOT is deployed and the site is here:
> http://maven.apache.org/plugins/maven-enforcer-plugin/ (just
> deployed so
> give it a little bit to completely update)
>
>
>
> If all goes well and no major issues are uncovered, then I think it's
> ready for staging and a vote.
>
>
>
> Thanks,
>
> Brian
>
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-enforcer-plugin
Posted by Jason Dillon <ja...@planet57.com>.
Seems a wee bit odd that you have "enforcer:enforce" which handles
maven version and java version, then "enforcer:os" which handles os
stuff. I'd rather have enforcer:require-maven, enforcer:require-
java, enforcer:require-os, *
I'm also not keen on the version range muck... but I guess its more
flexible that the 1.0+ and 1.0* stuff I was using. Still though the
version range specification never really felt natural to me ;-)
--jason
On Mar 19, 2007, at 9:04 PM, Brian E. Fox wrote:
> There is a new plugin that I'd like to get some feedback on,
> particularly on non-windows os's and the unit tests.
>
>
>
> The maven-enforcer-plugin picks up where <prerequisites> leaves off
> and
> allows control over the maven, jdk and os versions of a build.
>
>
>
> This plugin was initially conceived here:
>
> http://www.nabble.com/Control-of-maven-using-prerequisites-
> tf3231437s177
> .html#a8979318
>
> And here:
>
> http://www.nabble.com/Why-is-prerequisites-not-inherited--
> tf3236197s177.
> html#a9016296
>
>
>
> 1.0-alpha-1-SNAPSHOT is deployed and the site is here:
> http://maven.apache.org/plugins/maven-enforcer-plugin/ (just
> deployed so
> give it a little bit to completely update)
>
>
>
> If all goes well and no major issues are uncovered, then I think it's
> ready for staging and a vote.
>
>
>
> Thanks,
>
> Brian
>
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: maven-enforcer-plugin
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I thought that the Maven version parsing takes the -xx as a build
number? I'm internally reformatting the jdk version into something that
Maven understands.
-----Original Message-----
From: Jerome Lacoste [mailto:jerome.lacoste@gmail.com]
Sent: Friday, March 30, 2007 1:11 PM
To: Maven Developers List
Subject: Re: maven-enforcer-plugin
On 3/30/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> I know what changed, but not why it's broken yet. I changed the Java
> rule a little to support the build number of java instead of just 3
> digits like before. The parsing is correct according to the unit
> tests, but perhaps the version ranging isn't doing what I think.
note that there's a difference between 1.5.0-07 and 1.5.0_07, maybe
that's where your issue is ?
J
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional
commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-enforcer-plugin
Posted by Jerome Lacoste <je...@gmail.com>.
On 3/30/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> I know what changed, but not why it's broken yet. I changed the Java
> rule a little to support the build number of java instead of just 3
> digits like before. The parsing is correct according to the unit tests,
> but perhaps the version ranging isn't doing what I think.
note that there's a difference between 1.5.0-07 and 1.5.0_07, maybe
that's where your issue is ?
J
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: maven-enforcer-plugin
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I know what changed, but not why it's broken yet. I changed the Java
rule a little to support the build number of java instead of just 3
digits like before. The parsing is correct according to the unit tests,
but perhaps the version ranging isn't doing what I think.
-----Original Message-----
From: Jason Dillon [mailto:jason.dillon@gmail.com] On Behalf Of Jason
Dillon
Sent: Friday, March 30, 2007 3:43 AM
To: Maven Developers List
Subject: Re: maven-enforcer-plugin
I've no idea what is wrong... though I didn't look to hard. I rolled
back Geronimo to use 1.0-alpha-1-20070328.035547-9 which is happy.
Hopefully you can figure out whats hosed and publish a new snapshot
so I can remove my hack.
--jason
On Mar 30, 2007, at 12:27 AM, Jason Dillon wrote:
> Something is busted in the latest snapshot...
>
> I'm seeing:
>
> <snip>
> [INFO] Detected Maven Version: 2.0.5 is allowed in the range [2.0.5,).
> [WARNING] Rule 0: RequireJavaVersion failed with message: Detected
> JDK Version: 1.5.0-07 is not in the allowed range [1.5,1.6).
> </snip>
>
> java -version says:
>
> <snip>
> java version "1.5.0_07"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164)
> Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing)
> </snip>
>
> Why is "1.5.0-07" not in this range "[1.5,1.6)"?
>
> The exact same configuration was working about 30 minutes ago
> (before Mvn decided to refresh snapshots).
>
> * * *
>
> I'll look into it if I have time... but something is broken :-(
>
> --jason
>
>
> On Mar 29, 2007, at 8:58 PM, Brian E. Fox wrote:
>
>> I reimplemented the enforcer plugin along the lines of Jason D's
>> idea[1]
>> and I think this is a much more extensible solution. The rules now
>> implement a common interface in shared/maven-enforcer-rule-api and
>> users
>> will be able to inject their own custom rules. By defining the
>> interface
>> external to the plugin, the Lint idea that JVZ put out[2] should
>> be able
>> to invoke these rules, as will IDEs.
>>
>> Please take a look at the site to see how the plugin works and
>> provide
>> any suggestions. I still need to document how to create your own
>> rules
>> and inject them, but I believe everything else is covered. A
>> snapshot of
>> 1.0-alpha-1 has also been deployed for testing. (I believe
>> Geronimo is
>> already using it)
>>
>> http://maven.apache.org/plugins/maven-enforcer-plugin (just
>> deployed,
>> may take a while to refresh)
>>
>> [1]
>> http://www.nabble.com/maven-enforcer-plugin-
>> tf3431452s177.html#a9565974
>> [2] http://www.nabble.com/Maven-Lint-tf3462956s177.html#a9661545
>>
>> -----Original Message-----
>> From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
>> Sent: Tuesday, March 20, 2007 12:05 AM
>> To: Maven Developers List
>> Subject: maven-enforcer-plugin
>>
>> There is a new plugin that I'd like to get some feedback on,
>> particularly on non-windows os's and the unit tests.
>>
>>
>>
>> The maven-enforcer-plugin picks up where <prerequisites> leaves
>> off and
>> allows control over the maven, jdk and os versions of a build.
>>
>>
>>
>> This plugin was initially conceived here:
>>
>> http://www.nabble.com/Control-of-maven-using-prerequisites-
>> tf3231437s177
>> .html#a8979318
>>
>> And here:
>>
>> http://www.nabble.com/Why-is-prerequisites-not-inherited--
>> tf3236197s177.
>> html#a9016296
>>
>>
>>
>> 1.0-alpha-1-SNAPSHOT is deployed and the site is here:
>> http://maven.apache.org/plugins/maven-enforcer-plugin/ (just
>> deployed so
>> give it a little bit to completely update)
>>
>>
>>
>> If all goes well and no major issues are uncovered, then I think it's
>> ready for staging and a vote.
>>
>>
>>
>> Thanks,
>>
>> Brian
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-enforcer-plugin
Posted by Jason Dillon <ja...@planet57.com>.
I've no idea what is wrong... though I didn't look to hard. I rolled
back Geronimo to use 1.0-alpha-1-20070328.035547-9 which is happy.
Hopefully you can figure out whats hosed and publish a new snapshot
so I can remove my hack.
--jason
On Mar 30, 2007, at 12:27 AM, Jason Dillon wrote:
> Something is busted in the latest snapshot...
>
> I'm seeing:
>
> <snip>
> [INFO] Detected Maven Version: 2.0.5 is allowed in the range [2.0.5,).
> [WARNING] Rule 0: RequireJavaVersion failed with message: Detected
> JDK Version: 1.5.0-07 is not in the allowed range [1.5,1.6).
> </snip>
>
> java -version says:
>
> <snip>
> java version "1.5.0_07"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164)
> Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing)
> </snip>
>
> Why is "1.5.0-07" not in this range "[1.5,1.6)"?
>
> The exact same configuration was working about 30 minutes ago
> (before Mvn decided to refresh snapshots).
>
> * * *
>
> I'll look into it if I have time... but something is broken :-(
>
> --jason
>
>
> On Mar 29, 2007, at 8:58 PM, Brian E. Fox wrote:
>
>> I reimplemented the enforcer plugin along the lines of Jason D's
>> idea[1]
>> and I think this is a much more extensible solution. The rules now
>> implement a common interface in shared/maven-enforcer-rule-api and
>> users
>> will be able to inject their own custom rules. By defining the
>> interface
>> external to the plugin, the Lint idea that JVZ put out[2] should
>> be able
>> to invoke these rules, as will IDEs.
>>
>> Please take a look at the site to see how the plugin works and
>> provide
>> any suggestions. I still need to document how to create your own
>> rules
>> and inject them, but I believe everything else is covered. A
>> snapshot of
>> 1.0-alpha-1 has also been deployed for testing. (I believe
>> Geronimo is
>> already using it)
>>
>> http://maven.apache.org/plugins/maven-enforcer-plugin (just
>> deployed,
>> may take a while to refresh)
>>
>> [1]
>> http://www.nabble.com/maven-enforcer-plugin-
>> tf3431452s177.html#a9565974
>> [2] http://www.nabble.com/Maven-Lint-tf3462956s177.html#a9661545
>>
>> -----Original Message-----
>> From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
>> Sent: Tuesday, March 20, 2007 12:05 AM
>> To: Maven Developers List
>> Subject: maven-enforcer-plugin
>>
>> There is a new plugin that I'd like to get some feedback on,
>> particularly on non-windows os's and the unit tests.
>>
>>
>>
>> The maven-enforcer-plugin picks up where <prerequisites> leaves
>> off and
>> allows control over the maven, jdk and os versions of a build.
>>
>>
>>
>> This plugin was initially conceived here:
>>
>> http://www.nabble.com/Control-of-maven-using-prerequisites-
>> tf3231437s177
>> .html#a8979318
>>
>> And here:
>>
>> http://www.nabble.com/Why-is-prerequisites-not-inherited--
>> tf3236197s177.
>> html#a9016296
>>
>>
>>
>> 1.0-alpha-1-SNAPSHOT is deployed and the site is here:
>> http://maven.apache.org/plugins/maven-enforcer-plugin/ (just
>> deployed so
>> give it a little bit to completely update)
>>
>>
>>
>> If all goes well and no major issues are uncovered, then I think it's
>> ready for staging and a vote.
>>
>>
>>
>> Thanks,
>>
>> Brian
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-enforcer-plugin
Posted by Jason Dillon <ja...@planet57.com>.
Something is busted in the latest snapshot...
I'm seeing:
<snip>
[INFO] Detected Maven Version: 2.0.5 is allowed in the range [2.0.5,).
[WARNING] Rule 0: RequireJavaVersion failed with message: Detected
JDK Version: 1.5.0-07 is not in the allowed range [1.5,1.6).
</snip>
java -version says:
<snip>
java version "1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164)
Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing)
</snip>
Why is "1.5.0-07" not in this range "[1.5,1.6)"?
The exact same configuration was working about 30 minutes ago (before
Mvn decided to refresh snapshots).
* * *
I'll look into it if I have time... but something is broken :-(
--jason
On Mar 29, 2007, at 8:58 PM, Brian E. Fox wrote:
> I reimplemented the enforcer plugin along the lines of Jason D's
> idea[1]
> and I think this is a much more extensible solution. The rules now
> implement a common interface in shared/maven-enforcer-rule-api and
> users
> will be able to inject their own custom rules. By defining the
> interface
> external to the plugin, the Lint idea that JVZ put out[2] should be
> able
> to invoke these rules, as will IDEs.
>
> Please take a look at the site to see how the plugin works and provide
> any suggestions. I still need to document how to create your own rules
> and inject them, but I believe everything else is covered. A
> snapshot of
> 1.0-alpha-1 has also been deployed for testing. (I believe Geronimo is
> already using it)
>
> http://maven.apache.org/plugins/maven-enforcer-plugin (just deployed,
> may take a while to refresh)
>
> [1]
> http://www.nabble.com/maven-enforcer-plugin-
> tf3431452s177.html#a9565974
> [2] http://www.nabble.com/Maven-Lint-tf3462956s177.html#a9661545
>
> -----Original Message-----
> From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
> Sent: Tuesday, March 20, 2007 12:05 AM
> To: Maven Developers List
> Subject: maven-enforcer-plugin
>
> There is a new plugin that I'd like to get some feedback on,
> particularly on non-windows os's and the unit tests.
>
>
>
> The maven-enforcer-plugin picks up where <prerequisites> leaves off
> and
> allows control over the maven, jdk and os versions of a build.
>
>
>
> This plugin was initially conceived here:
>
> http://www.nabble.com/Control-of-maven-using-prerequisites-
> tf3231437s177
> .html#a8979318
>
> And here:
>
> http://www.nabble.com/Why-is-prerequisites-not-inherited--
> tf3236197s177.
> html#a9016296
>
>
>
> 1.0-alpha-1-SNAPSHOT is deployed and the site is here:
> http://maven.apache.org/plugins/maven-enforcer-plugin/ (just
> deployed so
> give it a little bit to completely update)
>
>
>
> If all goes well and no major issues are uncovered, then I think it's
> ready for staging and a vote.
>
>
>
> Thanks,
>
> Brian
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: maven-enforcer-plugin
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>More explicitly:
>[INFO] Used undeclared dependencies:
>[WARNING] None
Ah, that's the dependency plugin. Yes I already fixed that but not
before it was staged and a vote called.
> I confused verify with validate so I'll change that. I thought you
could
> bind it to another phase if you want, but if you don't specify one, it
> will go with the mojo default?
>Perhaps, I have not yet tried...
I just double checked that you can override it. I'm not able to get the
plugin to work with validate or initialize, I'm not sure why. There
doesn't appear to be a common lifecycle between default and site, so
there's now way I can bind it to both by default, but a user could.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-enforcer-plugin
Posted by Jerome Lacoste <je...@gmail.com>.
On 4/3/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
>
> >some more feedback:
> >* Is that useful ?
> >[WARNING] None
>
> I'll remove that, not sure where it's from.
More explicitly:
[INFO] Used undeclared dependencies:
[WARNING] None
> >* enforce-one mojo attached to verify phase. I would have preferred
> >the build to fail as early as possible if it is to tell me that I am
> >using the wrong JDK/maven version... Shouldn't we let the user decide
> >of the phase to attach the mojo to ?
>
> I confused verify with validate so I'll change that. I thought you could
> bind it to another phase if you want, but if you don't specify one, it
> will go with the mojo default?
Perhaps, I have not yet tried...
J
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: maven-enforcer-plugin
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>some more feedback:
>* Is that useful ?
>[WARNING] None
I'll remove that, not sure where it's from.
>* enforce-one mojo attached to verify phase. I would have preferred
>the build to fail as early as possible if it is to tell me that I am
>using the wrong JDK/maven version... Shouldn't we let the user decide
>of the phase to attach the mojo to ?
I confused verify with validate so I'll change that. I thought you could
bind it to another phase if you want, but if you don't specify one, it
will go with the mojo default?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-enforcer-plugin
Posted by Jerome Lacoste <je...@gmail.com>.
On 4/3/07, Jerome Lacoste <je...@gmail.com> wrote:
> On 4/3/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> > Ok, a little more refactoring. The Custom rules can now get to the
> > ExpressionEvaluator so they can get pretty much anything a plugin could
> > get. The sites are updated to contain info about the standard rules and
> > the custom rule creation:
> > http://maven.apache.org/plugins/maven-enforcer-plugin/
> > http://maven.apache.org/shared/maven-enforcer-rule-api/index.html
> >
> > I'll let this linger for a day or so and then call a vote if nothing
> > turns up.
>
> - typo in the usage.html
>
> </requireMavenVesion> -> </requireMavenVersion>
some more feedback:
* Is that useful ?
[WARNING] None
* enforce-one mojo attached to verify phase. I would have preferred
the build to fail as early as possible if it is to tell me that I am
using the wrong JDK/maven version... Shouldn't we let the user decide
of the phase to attach the mojo to ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-enforcer-plugin
Posted by Jerome Lacoste <je...@gmail.com>.
On 4/3/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> Ok, a little more refactoring. The Custom rules can now get to the
> ExpressionEvaluator so they can get pretty much anything a plugin could
> get. The sites are updated to contain info about the standard rules and
> the custom rule creation:
> http://maven.apache.org/plugins/maven-enforcer-plugin/
> http://maven.apache.org/shared/maven-enforcer-rule-api/index.html
>
> I'll let this linger for a day or so and then call a vote if nothing
> turns up.
- typo in the usage.html
</requireMavenVesion> -> </requireMavenVersion>
- would there be a way to make sure the enforcer runs for every maven
invocation, not just in the default lifecycle ? E.g. mvn site doesn't
trigger the check.
- finally do we want to provide a report?
-- if so, we perhaps need to add a mechanism to allow the rule
information to be displayed (visitor pattern for the rule? description
in a particular place ? Auto-generated information ?)
-- would there be a way to make this report part of the project
information (not a 'usual' report)?
J
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: maven-enforcer-plugin
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Ok I understand now. Lets punt alpha-1 and then we can play around with
various options to get this information. It will probably represent an
addition to the rule interface so it won't be intrusive (and if it is,
well it's alpha-1 ;-) )
-----Original Message-----
From: Jerome Lacoste [mailto:jerome.lacoste@gmail.com]
Sent: Tuesday, April 03, 2007 7:05 PM
To: Maven Developers List
Subject: Re: maven-enforcer-plugin
On 4/3/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> > The Require OS Version rules docs is using <goal>os</goal> instead
of
>
> ><goal>require</goal> (or <goal>require-once</goal>).
>
> Good catch. I'll make that change.
>
> > Is it close to time for a release of 1.0-alpha-1 of this puppy yet?
>
> Getting there. I want to explore Jerome's comments about reports and a
> vistor pattern. I haven't spent a lot of time thinking about it, but
I'm
> not sure how a visitor would help here. We really are only interested
in
> the message coming back. A report mojo could catch all the rule
results
> and report them. Comments? What am I missing?
Don't block the release of alpha-1 for that.
I wanted to have a report that says: this project requires maven 2.0.6
and SDK 1.5 without having to look at the pom.
Why a Visitor? Because you can specify your rule implementation, and
that might represent a complex rule, so I thought that only the rule
would be able to know about its configuration and the meaning of the
values. I don't like the idea in particular but that was the first one
that came to my head.
Another idea is to just publish the XML fragment for the plugin
configuration with each node linked to the rule APIs for further
documentation. That should be sufficient and simpler...
Cheers,
Jerome
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-enforcer-plugin
Posted by Jerome Lacoste <je...@gmail.com>.
On 4/3/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> > The Require OS Version rules docs is using <goal>os</goal> instead of
>
> ><goal>require</goal> (or <goal>require-once</goal>).
>
> Good catch. I'll make that change.
>
> > Is it close to time for a release of 1.0-alpha-1 of this puppy yet?
>
> Getting there. I want to explore Jerome's comments about reports and a
> vistor pattern. I haven't spent a lot of time thinking about it, but I'm
> not sure how a visitor would help here. We really are only interested in
> the message coming back. A report mojo could catch all the rule results
> and report them. Comments? What am I missing?
Don't block the release of alpha-1 for that.
I wanted to have a report that says: this project requires maven 2.0.6
and SDK 1.5 without having to look at the pom.
Why a Visitor? Because you can specify your rule implementation, and
that might represent a complex rule, so I thought that only the rule
would be able to know about its configuration and the meaning of the
values. I don't like the idea in particular but that was the first one
that came to my head.
Another idea is to just publish the XML fragment for the plugin
configuration with each node linked to the rule APIs for further
documentation. That should be sufficient and simpler...
Cheers,
Jerome
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-enforcer-plugin
Posted by Jason Dillon <ja...@planet57.com>.
On Apr 3, 2007, at 1:24 PM, Brian E. Fox wrote:
>> Is it close to time for a release of 1.0-alpha-1 of this puppy yet?
>
> Getting there. I want to explore Jerome's comments about reports and a
> vistor pattern. I haven't spent a lot of time thinking about it,
> but I'm
> not sure how a visitor would help here. We really are only
> interested in
> the message coming back. A report mojo could catch all the rule
> results
> and report them. Comments? What am I missing?
>
> I don't want to do a release until we can be relatively sure the
> interface for the rules won't change.
This is an 1.0-alpha-1 release... I don't see any harm in making one
right now, and then if needed an alpha-2 if something internal
changes dramatically.
I would like to use this plugin for all of the Geronimo builds... but
a few are going to be coming up for release soon, and well, until
there is a release of this I can't really use it for those projects.
I would like to see 1.0-alpha-1 go out very, very soon so that folks
can really start using it.
--jason
> -----Original Message-----
> From: Jason Dillon [mailto:jason.dillon@gmail.com] On Behalf Of Jason
> Dillon
> Sent: Tuesday, April 03, 2007 3:51 PM
> To: Maven Developers List
> Subject: Re: maven-enforcer-plugin
>
> * * *
>
> Is it close to time for a release of 1.0-alpha-1 of this puppy yet?
>
> --jason
>
>
> On Apr 2, 2007, at 7:31 PM, Brian E. Fox wrote:
>
>> Ok, a little more refactoring. The Custom rules can now get to the
>> ExpressionEvaluator so they can get pretty much anything a plugin
>> could
>> get. The sites are updated to contain info about the standard rules
>> and
>> the custom rule creation:
>> http://maven.apache.org/plugins/maven-enforcer-plugin/
>> http://maven.apache.org/shared/maven-enforcer-rule-api/index.html
>>
>> I'll let this linger for a day or so and then call a vote if nothing
>> turns up.
>>
>> Thanks,
>> Brian
>>
>> -----Original Message-----
>> From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
>> Sent: Thursday, March 29, 2007 11:59 PM
>> To: Maven Developers List
>> Subject: RE: maven-enforcer-plugin
>>
>> I reimplemented the enforcer plugin along the lines of Jason D's
>> idea[1]
>> and I think this is a much more extensible solution. The rules now
>> implement a common interface in shared/maven-enforcer-rule-api and
>> users
>> will be able to inject their own custom rules. By defining the
>> interface
>> external to the plugin, the Lint idea that JVZ put out[2] should be
>> able
>> to invoke these rules, as will IDEs.
>>
>> Please take a look at the site to see how the plugin works and
>> provide
>> any suggestions. I still need to document how to create your own
>> rules
>> and inject them, but I believe everything else is covered. A
>> snapshot of
>> 1.0-alpha-1 has also been deployed for testing. (I believe
>> Geronimo is
>> already using it)
>>
>> http://maven.apache.org/plugins/maven-enforcer-plugin (just
>> deployed,
>> may take a while to refresh)
>>
>> [1]
>> http://www.nabble.com/maven-enforcer-plugin-
>> tf3431452s177.html#a9565974
>> [2] http://www.nabble.com/Maven-Lint-tf3462956s177.html#a9661545
>>
>> -----Original Message-----
>> From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
>> Sent: Tuesday, March 20, 2007 12:05 AM
>> To: Maven Developers List
>> Subject: maven-enforcer-plugin
>>
>> There is a new plugin that I'd like to get some feedback on,
>> particularly on non-windows os's and the unit tests.
>>
>>
>>
>> The maven-enforcer-plugin picks up where <prerequisites> leaves off
>> and
>> allows control over the maven, jdk and os versions of a build.
>>
>>
>>
>> This plugin was initially conceived here:
>>
>> http://www.nabble.com/Control-of-maven-using-prerequisites-
>> tf3231437s177
>> .html#a8979318
>>
>> And here:
>>
>> http://www.nabble.com/Why-is-prerequisites-not-inherited--
>> tf3236197s177.
>> html#a9016296
>>
>>
>>
>> 1.0-alpha-1-SNAPSHOT is deployed and the site is here:
>> http://maven.apache.org/plugins/maven-enforcer-plugin/ (just
>> deployed so
>> give it a little bit to completely update)
>>
>>
>>
>> If all goes well and no major issues are uncovered, then I think it's
>> ready for staging and a vote.
>>
>>
>>
>> Thanks,
>>
>> Brian
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: maven-enforcer-plugin
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
> The Require OS Version rules docs is using <goal>os</goal> instead of
><goal>require</goal> (or <goal>require-once</goal>).
Good catch. I'll make that change.
> Is it close to time for a release of 1.0-alpha-1 of this puppy yet?
Getting there. I want to explore Jerome's comments about reports and a
vistor pattern. I haven't spent a lot of time thinking about it, but I'm
not sure how a visitor would help here. We really are only interested in
the message coming back. A report mojo could catch all the rule results
and report them. Comments? What am I missing?
I don't want to do a release until we can be relatively sure the
interface for the rules won't change.
-----Original Message-----
From: Jason Dillon [mailto:jason.dillon@gmail.com] On Behalf Of Jason
Dillon
Sent: Tuesday, April 03, 2007 3:51 PM
To: Maven Developers List
Subject: Re: maven-enforcer-plugin
* * *
Is it close to time for a release of 1.0-alpha-1 of this puppy yet?
--jason
On Apr 2, 2007, at 7:31 PM, Brian E. Fox wrote:
> Ok, a little more refactoring. The Custom rules can now get to the
> ExpressionEvaluator so they can get pretty much anything a plugin
> could
> get. The sites are updated to contain info about the standard rules
> and
> the custom rule creation:
> http://maven.apache.org/plugins/maven-enforcer-plugin/
> http://maven.apache.org/shared/maven-enforcer-rule-api/index.html
>
> I'll let this linger for a day or so and then call a vote if nothing
> turns up.
>
> Thanks,
> Brian
>
> -----Original Message-----
> From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
> Sent: Thursday, March 29, 2007 11:59 PM
> To: Maven Developers List
> Subject: RE: maven-enforcer-plugin
>
> I reimplemented the enforcer plugin along the lines of Jason D's
> idea[1]
> and I think this is a much more extensible solution. The rules now
> implement a common interface in shared/maven-enforcer-rule-api and
> users
> will be able to inject their own custom rules. By defining the
> interface
> external to the plugin, the Lint idea that JVZ put out[2] should be
> able
> to invoke these rules, as will IDEs.
>
> Please take a look at the site to see how the plugin works and provide
> any suggestions. I still need to document how to create your own rules
> and inject them, but I believe everything else is covered. A
> snapshot of
> 1.0-alpha-1 has also been deployed for testing. (I believe Geronimo is
> already using it)
>
> http://maven.apache.org/plugins/maven-enforcer-plugin (just deployed,
> may take a while to refresh)
>
> [1]
> http://www.nabble.com/maven-enforcer-plugin-
> tf3431452s177.html#a9565974
> [2] http://www.nabble.com/Maven-Lint-tf3462956s177.html#a9661545
>
> -----Original Message-----
> From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
> Sent: Tuesday, March 20, 2007 12:05 AM
> To: Maven Developers List
> Subject: maven-enforcer-plugin
>
> There is a new plugin that I'd like to get some feedback on,
> particularly on non-windows os's and the unit tests.
>
>
>
> The maven-enforcer-plugin picks up where <prerequisites> leaves off
> and
> allows control over the maven, jdk and os versions of a build.
>
>
>
> This plugin was initially conceived here:
>
> http://www.nabble.com/Control-of-maven-using-prerequisites-
> tf3231437s177
> .html#a8979318
>
> And here:
>
> http://www.nabble.com/Why-is-prerequisites-not-inherited--
> tf3236197s177.
> html#a9016296
>
>
>
> 1.0-alpha-1-SNAPSHOT is deployed and the site is here:
> http://maven.apache.org/plugins/maven-enforcer-plugin/ (just
> deployed so
> give it a little bit to completely update)
>
>
>
> If all goes well and no major issues are uncovered, then I think it's
> ready for staging and a vote.
>
>
>
> Thanks,
>
> Brian
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-enforcer-plugin
Posted by Jason Dillon <ja...@planet57.com>.
The Require OS Version rules docs is using <goal>os</goal> instead of
<goal>require</goal> (or <goal>require-once</goal>).
* * *
Is it close to time for a release of 1.0-alpha-1 of this puppy yet?
--jason
On Apr 2, 2007, at 7:31 PM, Brian E. Fox wrote:
> Ok, a little more refactoring. The Custom rules can now get to the
> ExpressionEvaluator so they can get pretty much anything a plugin
> could
> get. The sites are updated to contain info about the standard rules
> and
> the custom rule creation:
> http://maven.apache.org/plugins/maven-enforcer-plugin/
> http://maven.apache.org/shared/maven-enforcer-rule-api/index.html
>
> I'll let this linger for a day or so and then call a vote if nothing
> turns up.
>
> Thanks,
> Brian
>
> -----Original Message-----
> From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
> Sent: Thursday, March 29, 2007 11:59 PM
> To: Maven Developers List
> Subject: RE: maven-enforcer-plugin
>
> I reimplemented the enforcer plugin along the lines of Jason D's
> idea[1]
> and I think this is a much more extensible solution. The rules now
> implement a common interface in shared/maven-enforcer-rule-api and
> users
> will be able to inject their own custom rules. By defining the
> interface
> external to the plugin, the Lint idea that JVZ put out[2] should be
> able
> to invoke these rules, as will IDEs.
>
> Please take a look at the site to see how the plugin works and provide
> any suggestions. I still need to document how to create your own rules
> and inject them, but I believe everything else is covered. A
> snapshot of
> 1.0-alpha-1 has also been deployed for testing. (I believe Geronimo is
> already using it)
>
> http://maven.apache.org/plugins/maven-enforcer-plugin (just deployed,
> may take a while to refresh)
>
> [1]
> http://www.nabble.com/maven-enforcer-plugin-
> tf3431452s177.html#a9565974
> [2] http://www.nabble.com/Maven-Lint-tf3462956s177.html#a9661545
>
> -----Original Message-----
> From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
> Sent: Tuesday, March 20, 2007 12:05 AM
> To: Maven Developers List
> Subject: maven-enforcer-plugin
>
> There is a new plugin that I'd like to get some feedback on,
> particularly on non-windows os's and the unit tests.
>
>
>
> The maven-enforcer-plugin picks up where <prerequisites> leaves off
> and
> allows control over the maven, jdk and os versions of a build.
>
>
>
> This plugin was initially conceived here:
>
> http://www.nabble.com/Control-of-maven-using-prerequisites-
> tf3231437s177
> .html#a8979318
>
> And here:
>
> http://www.nabble.com/Why-is-prerequisites-not-inherited--
> tf3236197s177.
> html#a9016296
>
>
>
> 1.0-alpha-1-SNAPSHOT is deployed and the site is here:
> http://maven.apache.org/plugins/maven-enforcer-plugin/ (just
> deployed so
> give it a little bit to completely update)
>
>
>
> If all goes well and no major issues are uncovered, then I think it's
> ready for staging and a vote.
>
>
>
> Thanks,
>
> Brian
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: maven-enforcer-plugin
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Ok, a little more refactoring. The Custom rules can now get to the
ExpressionEvaluator so they can get pretty much anything a plugin could
get. The sites are updated to contain info about the standard rules and
the custom rule creation:
http://maven.apache.org/plugins/maven-enforcer-plugin/
http://maven.apache.org/shared/maven-enforcer-rule-api/index.html
I'll let this linger for a day or so and then call a vote if nothing
turns up.
Thanks,
Brian
-----Original Message-----
From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
Sent: Thursday, March 29, 2007 11:59 PM
To: Maven Developers List
Subject: RE: maven-enforcer-plugin
I reimplemented the enforcer plugin along the lines of Jason D's idea[1]
and I think this is a much more extensible solution. The rules now
implement a common interface in shared/maven-enforcer-rule-api and users
will be able to inject their own custom rules. By defining the interface
external to the plugin, the Lint idea that JVZ put out[2] should be able
to invoke these rules, as will IDEs.
Please take a look at the site to see how the plugin works and provide
any suggestions. I still need to document how to create your own rules
and inject them, but I believe everything else is covered. A snapshot of
1.0-alpha-1 has also been deployed for testing. (I believe Geronimo is
already using it)
http://maven.apache.org/plugins/maven-enforcer-plugin (just deployed,
may take a while to refresh)
[1]
http://www.nabble.com/maven-enforcer-plugin-tf3431452s177.html#a9565974
[2] http://www.nabble.com/Maven-Lint-tf3462956s177.html#a9661545
-----Original Message-----
From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
Sent: Tuesday, March 20, 2007 12:05 AM
To: Maven Developers List
Subject: maven-enforcer-plugin
There is a new plugin that I'd like to get some feedback on,
particularly on non-windows os's and the unit tests.
The maven-enforcer-plugin picks up where <prerequisites> leaves off and
allows control over the maven, jdk and os versions of a build.
This plugin was initially conceived here:
http://www.nabble.com/Control-of-maven-using-prerequisites-tf3231437s177
.html#a8979318
And here:
http://www.nabble.com/Why-is-prerequisites-not-inherited--tf3236197s177.
html#a9016296
1.0-alpha-1-SNAPSHOT is deployed and the site is here:
http://maven.apache.org/plugins/maven-enforcer-plugin/ (just deployed so
give it a little bit to completely update)
If all goes well and no major issues are uncovered, then I think it's
ready for staging and a vote.
Thanks,
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: maven-enforcer-plugin
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I reimplemented the enforcer plugin along the lines of Jason D's idea[1]
and I think this is a much more extensible solution. The rules now
implement a common interface in shared/maven-enforcer-rule-api and users
will be able to inject their own custom rules. By defining the interface
external to the plugin, the Lint idea that JVZ put out[2] should be able
to invoke these rules, as will IDEs.
Please take a look at the site to see how the plugin works and provide
any suggestions. I still need to document how to create your own rules
and inject them, but I believe everything else is covered. A snapshot of
1.0-alpha-1 has also been deployed for testing. (I believe Geronimo is
already using it)
http://maven.apache.org/plugins/maven-enforcer-plugin (just deployed,
may take a while to refresh)
[1]
http://www.nabble.com/maven-enforcer-plugin-tf3431452s177.html#a9565974
[2] http://www.nabble.com/Maven-Lint-tf3462956s177.html#a9661545
-----Original Message-----
From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
Sent: Tuesday, March 20, 2007 12:05 AM
To: Maven Developers List
Subject: maven-enforcer-plugin
There is a new plugin that I'd like to get some feedback on,
particularly on non-windows os's and the unit tests.
The maven-enforcer-plugin picks up where <prerequisites> leaves off and
allows control over the maven, jdk and os versions of a build.
This plugin was initially conceived here:
http://www.nabble.com/Control-of-maven-using-prerequisites-tf3231437s177
.html#a8979318
And here:
http://www.nabble.com/Why-is-prerequisites-not-inherited--tf3236197s177.
html#a9016296
1.0-alpha-1-SNAPSHOT is deployed and the site is here:
http://maven.apache.org/plugins/maven-enforcer-plugin/ (just deployed so
give it a little bit to completely update)
If all goes well and no major issues are uncovered, then I think it's
ready for staging and a vote.
Thanks,
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org