Displaying #maven-dev/2017-01-22.log:

Sun Jan 22 07:11:08 2017  tibor_:Joined the channel
Sun Jan 22 11:40:20 2017  rfscholte:Joined the channel
Sun Jan 22 15:17:46 2017  tibor_:Joined the channel
Sun Jan 22 16:44:06 2017  rfscholte:hboutemy: you're still the chair? ;) https://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-impl/team-list.html
Sun Jan 22 16:45:07 2017  hboutemy::)
Sun Jan 22 16:45:21 2017  hboutemy:I wanted to upgrade to parent 30, but it causes a failure
Sun Jan 22 16:45:30 2017  hboutemy:with enforcer rules
Sun Jan 22 16:45:59 2017  rfscholte:hmm, weird
Sun Jan 22 16:46:03 2017  hboutemy:this issue with enforcer rules hit me regularly
Sun Jan 22 16:46:32 2017  hboutemy:and while doing the release, I also found something strange that Michael Osipov had found, I imagine
Sun Jan 22 16:46:57 2017  hboutemy:if you do "mvn checkstyle:check && mvn checkstyle:check", it will break
Sun Jan 22 16:47:09 2017  hboutemy:but "mvn clean checkstyle:check" never fails
Sun Jan 22 16:47:26 2017  hboutemy:I still didn't find why
Sun Jan 22 16:47:38 2017  rfscholte:worth investigating
Sun Jan 22 16:48:22 2017  hboutemy:this is the genre of stupidity that makes me going nuts!
Sun Jan 22 16:49:02 2017  hboutemy:(and made me not understand why Micahel was "fixing" some license headers on package.java)
Sun Jan 22 16:53:06 2017  rfscholte:parent 30 works fine for me with MAR 1.0.3
Sun Jan 22 16:57:05 2017  hboutemy:it's not always failing
Sun Jan 22 16:57:40 2017  hboutemy:and IIRC, the rule failing is a MojoHaus rule
Sun Jan 22 16:57:52 2017  hboutemy:(which is in org.apache.maven package...)
Sun Jan 22 16:58:16 2017  hboutemy:this enforcer issue is making me nervous for monthes...
Sun Jan 22 16:58:44 2017  rfscholte:if you hit it again, please send me logs
Sun Jan 22 16:58:51 2017  hboutemy:ok
Sun Jan 22 16:58:56 2017  hboutemy:I'll try now
Sun Jan 22 16:59:22 2017  rfscholte:I have one issue with https://maven.apache.org/resolver-archives/resolver-LATEST/
Sun Jan 22 17:00:07 2017  rfscholte:the migration was all about licensing. There's no ware any link to the current new license
Sun Jan 22 17:00:20 2017  rfscholte:*nowhere
Sun Jan 22 17:02:33 2017  hboutemy:notice: like http://maven.apache.org/ref/3-LATEST/
Sun Jan 22 17:03:05 2017  hboutemy:but we did the job on normal components http://maven.apache.org/plugins/maven-compiler-plugin/
Sun Jan 22 17:03:48 2017  rfscholte:http://maven.apache.org/scm/index.html is again correct
Sun Jan 22 17:03:49 2017  hboutemy:it's easy to fix the site by cheating
Sun Jan 22 17:04:02 2017  hboutemy:are you ok with that?
Sun Jan 22 17:04:55 2017  rfscholte:cheating is fine, but especially here we need to be clear. (we're still using eclipse namespace in packages)
Sun Jan 22 17:05:20 2017  hboutemy:yes, sure
Sun Jan 22 17:05:48 2017  hboutemy:I let one week of review until Stephen put pressure to do the release :)
Sun Jan 22 17:05:49 2017  rfscholte:I'll make an issue for it for the next release
Sun Jan 22 17:05:56 2017  hboutemy:ok
Sun Jan 22 17:09:29 2017  hboutemy:stephenc: Hi Stephen
Sun Jan 22 17:09:50 2017  hboutemy:instead of "Maven Jenkinsfile finished with null" notifications
Sun Jan 22 17:10:31 2017  hboutemy:could it be "Maven branch xxx build yyy finished with zzz"?
Sun Jan 22 17:35:12 2017  hboutemy:rfscholte: try mvn -e -Preporting site
Sun Jan 22 17:35:33 2017  hboutemy:Caused by: java.lang.NullPointerException
Sun Jan 22 17:35:33 2017  hboutemy: at org.apache.maven.plugins.enforcer.EnforceBytecodeVersion.isBadArtifact(EnforceBytecodeVersion.java:221)
Sun Jan 22 17:36:14 2017  hboutemy:you need to build the site to see the failure: that's why not much people see the failure
Sun Jan 22 17:36:36 2017  hboutemy:(and sometimes, I get hit on simple normal builds: but that's only sometimes...)
Sun Jan 22 17:45:46 2017  rfscholte:hboutemy: got it
Sun Jan 22 17:46:22 2017  hboutemy:if you have time to enjoy analyzing this one :)
Sun Jan 22 17:47:01 2017  hboutemy:my first step at MojoHaus would have been to move the EnforceBytecodeVersion out of org.apache.maven.plugins.enforcer package
Sun Jan 22 17:47:16 2017  rfscholte:not possible
Sun Jan 22 17:47:16 2017  hboutemy:but I don't know if this is feasible
Sun Jan 22 17:47:55 2017  hboutemy:it's not great that you can't add custom rules in your own package name
Sun Jan 22 17:48:08 2017  hboutemy:but must use org.apache.maven.plugins.enforcer
Sun Jan 22 17:48:28 2017  rfscholte:well, you can, but that means you ned to add implementation="x.y.z.OtherRule"
Sun Jan 22 17:48:34 2017  rfscholte:it is a plexus issue
Sun Jan 22 17:49:00 2017  hboutemy:IIUC, "you" here is rules user
Sun Jan 22 17:49:27 2017  hboutemy:sure, we can't expect users to write such complex thing when wanting to use the rule
Sun Jan 22 17:50:26 2017  hboutemy:notice that EnforceBytecodeVersion could go in Maven Enforcer as standard rule )
Sun Jan 22 17:50:50 2017  rfscholte:unless we should start working with annotated rules
Sun Jan 22 17:51:14 2017  rfscholte:well, that's another discussion :)
Sun Jan 22 17:51:51 2017  rfscholte:all standard rules are Maven related, not technology related.
Sun Jan 22 17:51:58 2017  hboutemy:if annotated rules permit more flexible package names, I'm for it
Sun Jan 22 17:52:34 2017  hboutemy:is there some Jira issue to vote on? :)
Sun Jan 22 17:53:27 2017  rfscholte:no idea, not all my ideas and up in Jira :)
Sun Jan 22 17:54:44 2017  rfscholte:I don't see it
Sun Jan 22 17:56:29 2017  rfscholte:brb
Sun Jan 22 18:46:30 2017  rfscholte:hboutemy: it is still using extra-enforcer-rules 1.0-beta3, upgrading to 1.0-beta6 fixes the NPE
Sun Jan 22 20:18:50 2017  olamy:Joined the channel
Sun Jan 22 22:19:19 2017  hboutemy:ok, will need to update parent pom
Sun Jan 22 22:20:54 2017  hboutemy:ok, already done MPOM-136

Comments