You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Robert Scholte <rf...@apache.org> on 2013/06/24 20:24:24 UTC
Re: [CANCEL] [VOTE] Release Maven Enforcer version 1.3
Voted canceled
If too many external rules depend on the signatures of the standard rules,
then I have to cancel it.
Some dirty things were done with the exposed fields and of course
checkstyle complained about it. It's a shame it has become impossible to
remove this kind of "bugs".
If these signatures are such a real issue, we have some huge challenges
for 2.0.
And we're bound to the package, because of the way Plexus uses it to
initiate the Rules.
So for now I'll restore the visibility of the fields, mark them as
deprecated and refer to their getters and setters.
thanks,
Robert
Op Mon, 24 Jun 2013 11:22:31 +0200 schreef Baptiste MATHUS
<bm...@batmat.net>:
> +1 on that one: going onto a major version change like 2.x could be
> better
> here imo.
>
> I'm totally OK with releasing things that are more correct (not working
> correctly about artifact resolution here).
> But since this is likely to break a lot of internal rules (for example,
> it's gonna break 50% of the extra-enforcer-rules rules), it should be
> conveyed very clearly that it's an important upgrade.
>
> Cheers
>
> 2013/6/23 Mirko Friedenhagen <mf...@gmail.com>
>
>> Hello,
>>
>> I did the tests wrongly for extra-enforcer-rules, the new version of
>> enforcer is backwards incompatible:
>> org.apache.maven.plugins.enforcer.AbstractStandardEnforcerRule had a
>> public message field in 1.2, this is now (1.3) private and uses
>> getMessage and setMessage methods.
>>
>> This would mean a major update IMO.
>>
>> I can imagine this would mean a lot of private rules to break, so I
>> withdraw my +1 and make it
>> -1 (non-binding).
>>
>>
>> Regards
>> Mirko
>> Regards Mirko
>> --
>> http://illegalstateexception.blogspot.com/
>> https://github.com/mfriedenhagen/
>> https://bitbucket.org/mfriedenhagen/
>>
>>
>> On Sun, Jun 23, 2013 at 3:33 PM, Baptiste MATHUS <bm...@batmat.net>
>> wrote:
>> > Hi,
>> >
>> > No problem, I'll see how I can fix that.
>> >
>> > FWIW, I've just run the ITs of mojo's extra-enforcer-rules project
>> with
>> > m-enforcer-p:1.3.
>> > This gives:
>> > [ERROR] The following builds failed:
>> > [ERROR] * enforce-bytecode-version-jdkVersionOption\pom.xml
>> > [ERROR] * enforce-bytecode-version-with-banned-deps\pom.xml
>> > [ERROR] * enforce-bytecode-version-wo-banned-deps\pom.xml
>> > [ERROR] * mojo-1682\pom.xml
>> > [ERROR] * mojo-1731\pom.xml
>> > [ERROR] * mojo-1744\pom.xml
>> > [ERROR] * mojo-1769\pom.xml
>> > [ERROR] * mojo-1853\pom.xml
>> > [ERROR] * mojo-1929\pom.xml
>> > [ERROR] * require-property-diverges\pom.xml
>> > [ERROR] * smokes\pom.xml
>> >
>> > So, to sum up, the impacted rules are:
>> >
>> > - enforceBytecodeVersion
>> > - banDuplicateClasses
>> > - requirePropertyDiverges
>> >
>> >
>> > Cheers
>> >
>> >
>> >
>> > 2013/6/23 Robert Scholte <rf...@apache.org>
>> >
>> >> Hi Baptiste,
>> >>
>> >> you're hitting the result of the changes due to MENFORCER-42[1]
>> >> Up until 1.2 the dependencies were resolved instead of calculated.
>> >> So if you run 'mvn validate' you can't use the results of the
>> reactor,
>> >> since those files aren't available yet. So the build will fail or it
>> will
>> >> use artifacts from an older run. IMO both are wrong.
>> >>
>> >> The EnforceBytecodeVersion is an example of a rule which needs to be
>> bound
>> >> after compilation.
>> >> My suggestion is to rewrite the rule and let it depend on a
>> DependencyTree
>> >> instead of a DependencyGraph[2]
>> >>
>> >> I noticed that the extra-enforcer-rules depend on the (standard)
>> >> enforcer-rules. I think that could be improved by extracting abstract
>> >> classes to a separate module. That way we have a better separation on
>> >> concerns. That would be something for a next release.
>> >>
>> >> I'm not going to cancel the vote for this reason.
>> >>
>> >> Robert
>> >>
>> >> ps. Thanks for testing!
>> >>
>> >> [1] http://jira.codehaus.org/**browse/MENFORCER-42<
>> http://jira.codehaus.org/browse/MENFORCER-42>
>> >> [2] http://maven.apache.org/**shared/maven-dependency-tree/<
>> http://maven.apache.org/shared/maven-dependency-tree/>
>> >>
>> >>
>> >> Op Sun, 23 Jun 2013 11:45:30 +0200 schreef Baptiste MATHUS <
>> >> bmathus@batmat.net>:
>> >>
>> >> -0.9 (non binding).
>> >>>
>> >>> I just tested on a local project, codehaus mojo
>> EnforceBytecodeVersion
>> >>> fails with an NPE with m-enforcer-p 1.3 but correctly thows an
>> >>> EnforcerRuleException with 1.2.
>> >>> That is, as I am the one who wrote that rule, that's perfectly
>> possible
>> >>> I'm
>> >>> doing something stooopid in the code that gets revealed with this
>> new
>> >>> enforcer-p version.
>> >>>
>> >>> I've pasted the stack trace here: http://pastebin.com/3sHY0Fvf
>> >>>
>> >>> After a quick dive in the code, from the stack trace, seems like the
>> >>> following code:
>> >>> *private boolean isBadArtifact( Artifact a )** throws
>> >>> EnforcerRuleException*
>> >>> * {*
>> >>> * File f = a.getFile();*
>> >>> * if ( !f.getName().endsWith( ".jar" ) )*
>> >>> * {*
>> >>>
>> >>>
>> >>> fails because the returned File is null.
>> >>>
>> >>> Is this something that should always work. If you feel this is
>> correct
>> >>> code, then just let me know and I'll file the corresponding JIRA.
>> >>>
>> >>> Cheers
>> >>>
>> >>>
>> >>> 2013/6/23 Olivier Lamy <ol...@apache.org>
>> >>>
>> >>> +1
>> >>>>
>> >>>> 2013/6/22 Robert Scholte <rf...@apache.org>:
>> >>>> > Hi,
>> >>>> >
>> >>>> > We solved 15 issues:
>> >>>> >
>> >>>> http://jira.codehaus.org/**secure/ReleaseNote.jspa?**
>> >>>> projectId=11530&version=19011<
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=19011
>> >
>> >>>> >
>> >>>> > There are still a couple of issues left in JIRA:
>> >>>> >
>> >>>> http://jira.codehaus.org/**secure/IssueNavigator.jspa?**
>> >>>> reset=true&pid=11530&status=1<
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11530&status=1
>> >
>> >>>> >
>> >>>> > Staging repo:
>> >>>> >
>> https://repository.apache.org/**content/repositories/maven-**056/<
>> https://repository.apache.org/content/repositories/maven-056/>
>> >>>> >
>> >>>> https://repository.apache.org/**content/repositories/maven-**
>> >>>> 056/org/apache/maven/enforcer/**enforcer/1.3/enforcer-1.3-**
>> >>>> source-release.zip<
>> https://repository.apache.org/content/repositories/maven-056/org/apache/maven/enforcer/enforcer/1.3/enforcer-1.3-source-release.zip
>> >
>> >>>> >
>> >>>> > Staging site:
>> >>>> > http://maven.apache.org/**enforcer-archives/enforcer-**LATEST/<
>> http://maven.apache.org/enforcer-archives/enforcer-LATEST/>
>> >>>> >
>> >>>> > Guide to testing staged releases:
>> >>>> > http://maven.apache.org/**guides/development/guide-**
>> >>>> testing-releases.html<
>> http://maven.apache.org/guides/development/guide-testing-releases.html>
>> >>>> >
>> >>>> > Vote open for 72 hours.
>> >>>> >
>> >>>> > [ ] +1
>> >>>> > [ ] +0
>> >>>> > [ ] -1
>> >>>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org