As long as we're in alpha and beta releases we shouldn't bump the version.At
some moment we should have a 1.0, until then keep it -alpha-x or -beta-y Anders
started already a discussion about the changes.xml / jira-report.We should be
able to refer to the component-version, that's what I'd prefer. Robert> From:
[email protected]
> Date: Mon, 23 Apr 2012 23:43:05 +0200
> To: [email protected]
> Subject: Re: [mojo-dev] New release of extra-enforcer-rules?
>
> Hello,
>
> I have two questions before doing a release:
>
> 1) As we added 3 additional rules I would suggest bumping the version
> from 1.0-alpha-3-SNAPSHOT to 1.1-alpha-1. However this would mean we
> have to adjust the version in JIRA as well. What do you think?
>
> 2) http://mojo.codehaus.org/development/performing-a-release.html
> states that I should update the changes.xml. However I think the
> current opinion seems to be that all changes have to have a
> corresponding JIRA entry and extra-enforcer-rules has no changes.xml
> at all anyway :-).
>
> Regards Mirko
>
> On Mon, Apr 23, 2012 at 22:35, Robert Scholte <[email protected]> wrote:
> > Hi Mirko,
> >
> > I think we're good to go.
> > Do you want to pick up this release?
> >
> > -Robert
> >> To: [email protected]; [email protected]
> >> Date: Thu, 19 Apr 2012 23:29:01 +0200
> >> From: [email protected]
> >> Subject: Re: [mojo-dev] New release of extra-enforcer-rules?
> >
> >>
> >> Hi Mirko,
> >>
> >> it looks to me the name of the rule is wrong with your described
> >> intension.
> >> RequireContributorRoles would mean that a contributor requires a role
> >> The role isn't mandatory, so I think you shouldn't use Required as prefix,
> >> but maybe AllowedContributorRoles.
> >>
> >> I assumed that contributors and developers are different object, but now I
> >> see
> >> public class Developer extends Contributor
> >> That part could be reverted, although it looks a bit weird.
> >>
> >>
> >> On Thu, 19 Apr 2012 23:13:51 +0200, Mirko Friedenhagen
> >> <[email protected]> wrote:
> >>
> >> > Hello Robert,
> >> >
> >> > a) maybe the intentions of RequireContributorRoles and
> >> > RequireDeveloperRoles are not clear:
> >> >
> >> > - I did not want every developer or contributor to *have a role*, but
> >> > that certain roles are taken in a project, so the code checks that at
> >> > least one of the developers/contributors in a project has one of the
> >> > required roles. Say you always want to have someone to be the
> >> > "business engineer" in a project, so you define that this role is
> >> > taken at least by one of the contributors. So I changed the error
> >> > message to be:
> >> > "Found no %s representing role(s) '%s'", "developer|contributor",
> >> > rolesFromProperties
> >> > - Why did you pull down the getRolesFromProject method? It is
> >> > identical in both RequireContributorRoles and RequireDeveloperRoles
> >> > except of the input list :-).
> >> >
> >> >
> >> > b) In regards to RequirePropertyDiverges: I choose to compare against
> >> > a Xpp3Dom as plugins.get( MAVEN_ENFORCER_PLUGIN ).getConfiguration()
> >> > returns a Xpp3Dom which I otherwise would have had to parse again.
> >> >
> >> >
> >> > c) Unless someone wanted to extend the new rules, I like to minimize
> >> > visibility therefore I normally prefer the default (package) scope
> >> > instead of protected. This allows to write unit tests easily without
> >> > widening the API.
> >> >
> >> > Regards Mirko
> >> >
> >> > On Wed, Apr 18, 2012 at 23:00, Robert Scholte <[email protected]>
> >> > wrote:
> >> >> Mirko,
> >> >>
> >> >> some remarks:
> >> >> IMO requireRole would mean that every developer/contributor requires at
> >> >> least one role.
> >> >> But the code checks if the used roles are allowed. So i'd prefer to
> >> >> rename
> >> >> those rules.
> >> >> Don't you want to log the offending contributer/developer?
> >> >>
> >> >> If some properties are required, I think you should verfy them first.
> >> >> So if AbstractRequireRoles.requiredRoles (actually allowedRoles) is
> >> >> empty or
> >> >> RequirePropertyDiverges.property is empty the rule should fail
> >> >> immediately.
> >> >>
> >> >> The RequirePropertyDiverges looks like a pretty flat rule, so I don't
> >> >> see
> >> >> why need those Xpp3Dom objects, but I could be wrong here.
> >> >>
> >> >> -Robert
> >> >>
> >> >> ps. I've already made some changes to the code
> >> >> ________________________________
> >> >> From: [email protected]
> >> >> To: [email protected]
> >> >> Date: Mon, 16 Apr 2012 21:07:07 +0000
> >> >> Subject: RE: [mojo-dev] New release of extra-enforcer-rules?
> >> >>
> >> >>
> >> >> I'll try to have a look at it this week.
> >> >>
> >> >> Robert
> >> >>> From: [email protected]
> >> >>> Date: Sun, 15 Apr 2012 22:02:36 +0200
> >> >>> To: [email protected]
> >> >>> Subject: [mojo-dev] New release of extra-enforcer-rules?
> >> >>>
> >> >>> Hello,
> >> >>>
> >> >>> I have merged back my branch into the trunk which implements three new
> >> >>> rules for checking diverging properties from an ancestor project as
> >> >>> well as rules for checking certain roles for developers and
> >> >>> contributors are defined in a project. I have written unit tests as
> >> >>> well as invoker tests and am confident they should work.
> >> >>>
> >> >>> Are there any plans for releasing extra-enforcer-rules-1.0-alpha-3?
> >> >>>
> >> >>> Regards Mirko
> >> >>>
> >> >>> ---------------------------------------------------------------------
> >> >>> To unsubscribe from this list, please visit:
> >> >>>
> >> >>> http://xircles.codehaus.org/manage_email
> >> >>>
> >> >>>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe from this list, please visit:
> >> >
> >> > http://xircles.codehaus.org/manage_email
> >> >
> >> >
> >>
> >>
> >> --
> >> Using Opera's revolutionary email client: http://www.opera.com/mail/
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this list, please visit:
> >>
> >> http://xircles.codehaus.org/manage_email
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
