Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: neutral (nike.apache.org: 74.125.82.171 is neither permitted nor
 denied by domain of brianf@infinity.nu)
MIME-Version: 1.0
In-Reply-To: <AANLkTim5P5y+ZZ=yJFHujcARkbs7Ki4zt3tOdy=4s-F5@mail.gmail.com>
References: <AANLkTim5P5y+ZZ=yJFHujcARkbs7Ki4zt3tOdy=4s-F5@mail.gmail.com>
Date: Thu, 4 Nov 2010 14:12:44 -0400
Message-ID: <AANLkTin8bNLENrMnCuMUvdrbTj2eRyWZGgs14XxtABsK@mail.gmail.com>
Subject: Re: Auto apache version standard as an enforcer rule?
From: Brian Fox <brianf@infinity.nu>
To: Maven Developers List <dev@maven.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

> If I were to clean this up and construct an enforcer rule that
> demanded adherence to the letter of the law of the apache version
> standard, is something that would be allowed into the maven enforcer
> plugin?
>

Given a proper rule with tests, I would unlikely reject it out of hand.

> Or would the team prefer I continue to try to work the the clirr-mojo?
>

My gut though is that this might be better as a report than a rule. I
think an enforcer rule could get in the way of developers if as soon
as they made a breaking change, the build blew up on them. It would
make a bit more sense in a release profile but even there blowing up a
build is annoying.

What belongs in the enforcer vs other plugins is definitely a grey
area that has no great answer. Certainly I could make a rule to
duplicate checkstyle and pmd checks, but those plugins have ways of
failing the build already. The enforcer wasn't intended to become the
central place for all things that fail a build, although it could.

Given that there seems to be great overlap with the clirr stuff in
checking the api, it feels like the functionality should be there.
However, if you construct it as a separate plexus component, then both
clirr and the enforcer could use that shared code to provide multiple
ways to attack it.

> Give me a firm commitment (contingent on quality of course ) and I
> could have this done tonight.
>
> Rex
>
> ---------------------------------------------------------------------
> 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