Hi Hilco,
The site should list the new rule as @since 1.0-alpha-4 but if it
doesn't, I'll fix that.
The plugin does work in its new state. I need to fix a few critical
issues related to enforce-once before the release can be done.
-Original Message-
From: Hilco Wijbenga [mailto:[EMAIL PR
Hi Hilco,
The enforcer plugin requirePluginVersions rule intentionally scans
everything in your pom inheritance to see anything that isn't defined.
This also includes things you haven't declared but are being used by the
standard lifecycle (compile,install etc etc). The alternative is that
everytim
Hi Brian,
On Jan 10, 2008 5:40 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> The enforcer plugin requirePluginVersions rule intentionally scans
> everything in your pom inheritance to see anything that isn't defined.
> This also includes things you haven't declared but are being used by the
> stan
Hilco Wijbenga [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 10, 2008 9:29 PM
To: Maven Developers List
Subject: Re: Maven Enforcer Plugin
Hi Brian,
On Jan 10, 2008 5:40 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> The enforcer plugin requirePluginVersions rule intentionally scans
On Jan 10, 2008 6:33 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> Hilco, I'll have to take a deeper look, it's possible that I missed some
> other cases. I had to manually read and interpret the poms since I
> couldn't get them unmolested from the core. Can you open a jira and
> attach a sample so
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
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?
--jas
stuff falls into the same boat, why reinvent a syntax when one
already exists?
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED] 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 b
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 t
>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
doin
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,
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 ExecutableCapability matches the policy
implementation, otherwise returns fals
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...
...
...
[1.3,1.6]
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 e
Yes, me too.
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
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 <[EMAIL PROTEC
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
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
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 t
Something is busted in the latest snapshot...
I'm seeing:
[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).
java -version says:
java versio
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:
al Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED] 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-200703
On 3/30/07, Brian E. Fox <[EMAIL PROTECTED]> 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'
List
Subject: Re: maven-enforcer-plugin
On 3/30/07, Brian E. Fox <[EMAIL PROTECTED]> 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 corr
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
On 4/3/07, Brian E. Fox <[EMAIL PROTECTED]> 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://ma
On 4/3/07, Jerome Lacoste <[EMAIL PROTECTED]> wrote:
On 4/3/07, Brian E. Fox <[EMAIL PROTECTED]> 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
>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 le
On 4/3/07, Brian E. Fox <[EMAIL PROTECTED]> 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 pre
>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,
l 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:[EMAIL PROTECTED]
Sent: Thursday, March 29, 2007 11:59 PM
To: Maven Developers List
Subject: RE: maven-enforcer-plugin
I reimplemented the enforcer p
ntil we can be relatively sure the
interface for the rules won't change.
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED] 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
y, 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
Express
On 4/3/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> The Require OS Version rules docs is using os instead of
>require (or require-once).
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
te [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 03, 2007 7:05 PM
To: Maven Developers List
Subject: Re: maven-enforcer-plugin
On 4/3/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> > The Require OS Version rules docs is using os instead
of
>
> >require (or require-once).
>
&
Afternoon Karl!
dreading going out in the hot sun without SPF 1000 so Im dallying on the puter
for as long as I can
some situations I found for doxia (that you pointed out yesterday):
1)Tests wont compile clean e.g. Cast to (LinkItem) was never completed on
return from parent.getBody().getBrea
Hi Martin,
>
some situations I found for doxia (that you pointed out yesterday):
1)Tests wont compile clean e.g. Cast to (LinkItem) was never completed on
return from parent.getBody().getBreadcrumbs().get(0);
parentHref = "scp://parent.com/index.html";
linkItem =(LinkItem)parent.ge
Sure, I can take a look as I'm doing releases this week.
Hervé, you mind if I push out MENFORCER-144 to the next version so I can stage
a release?
https://jira.codehaus.org/secure/IssueNavigator.jspa?fixfor=18491&pid=11530&reset=true&show=View+%26gt%3B%26gt%3B
On Nov 20, 2012, at 11:54 AM, Josh
Hey Jason,
I can knock off an enforcer release even intoxicated by acute turkey
poisoning. On the other hand, I don't know enough to look for a better
solution to the forked execution issue that we've been discussing with
respect to the site plugin. Can I interest you in swapping?
--benson
On T
MENFORCER-144 fixed
I'd like to MENFORCER-145 before the release, please wait a few more hours
Regards,
Hervé
Le mardi 20 novembre 2012 12:02:40 Jason van Zyl a écrit :
> Sure, I can take a look as I'm doing releases this week.
>
> Hervé, you mind if I push out MENFORCER-144 to the next versio
No rush. Just figured while I'm in the release monkey seat I would try to push
it out.
On Nov 20, 2012, at 2:53 PM, Hervé BOUTEMY wrote:
> MENFORCER-144 fixed
>
> I'd like to MENFORCER-145 before the release, please wait a few more hours
>
> Regards,
>
> Hervé
>
> Le mardi 20 novembre 2012
While that sounds enticing... I'll stick with the enforcer release :-)
Happy to take a look later in the week once all the Maven 3.1.0 dependencies
are dealt with.
On Nov 20, 2012, at 1:28 PM, Benson Margulies wrote:
> Hey Jason,
>
> I can knock off an enforcer release even intoxicated by acu
Hi Jon,
I think that if this idea can help you it is worth to work on it.
Can you create a JIRA with your case ?
It would be great if you can also try to send a pull request with a
proposal,
We will be happy to see your code and eventually merge it.
Cheers
Enrico
Il sab 18 mag 2019, 06:48 Jon Har
Hi,
Issue https://issues.apache.org/jira/browse/MENFORCER-391 is waiting for
release of maven-dependency-tree
So first we should release maven-dependency-tree.
I will take care of it :-)
czw., 5 maj 2022 o 23:23 Filipe Roque
napisał(a):
> Hi,
>
> Can we get a release of maven-enforcer-plugin
Hi,
maven-dependency-tree was released and updated in maven-enforcer-plugin.
I'm going to release the maven-enforcer-plugin in a week or two.
Any help to clean up issues, review PR and testing before release are
appreciated from contributors.
Maybe some of the issues are also important and shou
A big thumb up for lowering Maven console output! Many Maven errors (and
outputs) are just very redundant and lost in ocean flood of log lines.
For the rest I'd leave to other team mates to chime in.
Thanks
T
On Mon, Jul 22, 2024, 09:25 Gyorgy Abraham
wrote:
> Dear Maven devs,
>
> At our compa
ged) <-- 3.12.0
[ERROR] org.slf4j:slf4j-api:1.7.36 (managed) <-- 1.7.32
[ERROR] com.fasterxml.jackson.core:jackson-databind:2.14.2 (managed) <-- 2.13.5
Cheers,
Gyorgy
Feladó: Tamás Cservenák
Dátum: hétfő, 2024. július 22. 9:43
Címzett: Maven Developers List
Tárgy: Re: [Maven Enf
g.slf4j:slf4j-api:1.7.36 (managed) <-- 1.7.32
> [ERROR] com.fasterxml.jackson.core:jackson-databind:2.14.2 (managed) <--
> 2.13.5
>
> Cheers,
> Gyorgy
>
> Feladó: Tamás Cservenák
> Dátum: hétfő, 2024. július 22. 9:43
> Címzett: Maven Developers List
> Tárgy: Re: [Maven Enforcer Plugin] In
Am 2024-07-24 um 19:37 schrieb Tamás Cservenák:
Howdy,
Seems @Michael Osipov rejected your jira request :(
Anyway, create pr and we will handle jira
Pity, because the reason was poorly written.
I am a bit confused now, because I tried to follow the contribution guide, in
which first step was to create a JIRA account.
Will send the PR soon, thanks for the inputs all.
Feladó: Michael Osipov
Dátum: szerda, 2024. július 24. 19:46
Címzett: dev@maven.apache.org
Tárgy: Re: [Maven Enforcer
On 2024/07/25 08:52:38 Gyorgy Abraham wrote:
> I am a bit confused now, because I tried to follow the contribution guide, in
> which first step was to create a JIRA account.
> Will send the PR soon, thanks for the inputs all.
Please create a new JIRA account request. I will approve it.
-
Thanks Michael, but in the meantime it was approved.
Feladó: Michael Osipov
Dátum: csütörtök, 2024. július 25. 16:00
Címzett: dev@maven.apache.org
Tárgy: RE: [Maven Enforcer Plugin] Intention to improve the output format
EXTERNAL EMAIL - Please use caution with links and attachments
On 2024
Hi,
in [1] MENFORCER-338, there is a comment that an exclusion/inclusion
list might be feasible.
If there is a release soon, such an upcoming PR will break the single
item in -M5.
Should this be altered before release?
[1] https://issues.apache.org/jira/browse/MENFORCER-338
Am Mi., 20. Jan. 20
Hello, just in case it is a blocker for a new milestone version, I've made
a corresponding PR to add exclusion/inclusion support [1], feel free to
have a look.
[1] https://github.com/apache/maven-enforcer/pull/86
ср, 20 янв. 2021 г. в 22:50, Benjamin Marwell :
> Hi,
>
> in [1] MENFORCER-338, the
Thanks for the PR!
We will review it soon. After that I will try to push for a release as
requested.
Am Mo., 25. Jan. 2021 um 00:43 Uhr schrieb Artem Krosheninnikov
:
>
> Hello, just in case it is a blocker for a new milestone version, I've made
> a corresponding PR to add exclusion/inclusion sup
Have you considered mailing the d...@mojo.codehaus.org group?
Have you considered raising a jira against the extra rules component
http://mojo.codehaus.org/extra-enforcer-rules/issue-tracking.html
Does your patch include tests?
Mailing the dev (in this case me) directly is liable to get you
spam
Losing most of my time to cucumber-jvm maven plugins (most of today), and to
the project in general...
Don't think maven land (proper) will see much love until I nail down
multithreaded browser based tests and push it in to the project.
Rex
On Jul 15, 2012, at 4:49 PM, Barrie Treloar wrote:
>
56 matches
Mail list logo
