+1 to proceed it would be great if you could create a issue to check those results
Am Di., 4. Sep. 2018 um 21:25 Uhr schrieb Paul Nicolucci < [email protected]>: > I get the following exception: > > [INFO] BUILD FAILURE > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 5.222 s > [INFO] Finished at: 2018-09-04T13:41:31-04:00 > [INFO] Final Memory: 53M/357M > [INFO] > ------------------------------------------------------------------------ > [ERROR] Failed to execute goal > org.codehaus.mojo:clirr-maven-plugin:2.4:clirr (default-cli) on project > myfaces-api: Execution default-cli of goal > org.codehaus.mojo:clirr-maven-plugin:2.4:clirr failed: Invalid byte tag in > constant pool: 18 -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.codehaus.mojo:clirr-maven-plugin:2.4:clirr (default-cli) on > project myfaces-api: Execution default-cli of goal > org.codehaus.mojo:clirr-maven-plugin:2.4:clirr failed: Invalid byte tag in > constant pool: 18 > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution > default-cli of goal org.codehaus.mojo:clirr-maven-plugin:2.4:clirr failed: > Invalid byte tag in constant pool: 18 > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) > ... 20 more > Caused by: org.apache.bcel.classfile.ClassFormatException: Invalid byte > tag in constant pool: 18 > at org.apache.bcel.classfile.Constant.readConstant(Constant.java:146) > at org.apache.bcel.classfile.ConstantPool.<init>(ConstantPool.java:67) > at > org.apache.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:222) > at org.apache.bcel.classfile.ClassParser.parse(ClassParser.java:136) > at > net.sf.clirr.core.internal.bcel.BcelTypeArrayBuilder.extractClass(BcelTypeArrayBuilder.java:135) > at > net.sf.clirr.core.internal.bcel.BcelTypeArrayBuilder.createClassSet(BcelTypeArrayBuilder.java:82) > at > org.codehaus.mojo.clirr.AbstractClirrMojo.resolvePreviousReleaseClasses(AbstractClirrMojo.java:336) > at > org.codehaus.mojo.clirr.AbstractClirrMojo.executeClirr(AbstractClirrMojo.java:219) > at org.codehaus.mojo.clirr.ClirrReport.doReport(ClirrReport.java:243) > at org.codehaus.mojo.clirr.ClirrReport.generate(ClirrReport.java:219) > at org.codehaus.mojo.clirr.ClirrReport.generate(ClirrReport.java:355) > at org.codehaus.mojo.clirr.ClirrReport.doExecute(ClirrReport.java:182) > at > org.codehaus.mojo.clirr.AbstractClirrMojo.execute(AbstractClirrMojo.java:200) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) > ... 21 more > [ERROR] > [ERROR] > [ERROR] For more information about the errors and possible solutions, > please read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the > command > [ERROR] mvn <goals> -rf :myfaces-api > > ************************************************************************************************************************************** > > ************************************************************************************************************************************** > > I've tried with both Java7 and Java8 on the PATH/JAVA_HOME and I get the > same error. > > The checklist mentions the use of japicmp as an alternative , however it > looks like that suggests running against the previous version of the > myfaces api not the Reference Implemenation 2.3.0 like the clirr plugin > does. If I run against the RI 2.3 org.glassfish/javax.faces/2.3.0 I get a > bunch of "MODIFIED" reports. > > Command: C:\binarycheck>java -jar > japicmp-0.13.0-jar-with-dependencies.jar -n myfaces-api > -2.3.2.jar -o javax.faces-api-2.3.jar --ignore-missing-classes --html-file > c:\bi > narycheck\results.html > > *(See attached file: results.html)* > > If I compare MyFaces 2.3.1 to MyFaces 2.3.2 then the report has fewer > "MODIFIED" issues: > > Command: C:\binarycheck>java -jar > japicmp-0.13.0-jar-with-dependencies.jar -n myfaces-api > -2.3.2.jar -o myfaces-api-2.3.1.jar --ignore-missing-classes --html-file > c:\bina > rycheck\results231.html > > *(See attached file: results231.html)* > > I think we'll likely need to use something other than clirr in the future > or determine how to get it working in our current code base. > > In the 2.3.1 -> 2.3.2 comparison the only changes in the api are: > 1) SearchExpressionContextFactory - removed constructor > SearchExpressionContextFactory and removed abstract from the getWrapped > method to match the javaDoc and pass compliance testing: > https://issues.apache.org/jira/browse/MYFACES-4231 > 2) UIWebSocket - updated made here > https://issues.apache.org/jira/browse/MYFACES-4232 also to match the > javadoc / pass compliance testing. > > *In summary I think release to release we are good, so in my opinion we > can move forward with the release and I can open a JIRA to address the > other potential problems in the 2.3.x code base relative to the Reference > Implementation for us to take a look at before the next release. Since > these look to have been there for awhile (since our myfaces 2.3.1 -> > myfaces 2.3.2 report doesn't have any issues besides the above) I don't > think it should prevent the 2.3.2 release.* > > Any objections to this plan? > > > Regards, > > Paul Nicolucci > [image: Inactive hide details for Thomas Andraschko ---09/04/2018 01:28:15 > PM---AFAIR mvn clirr:clirr See: https://urldefense.proofpoin]Thomas > Andraschko ---09/04/2018 01:28:15 PM---AFAIR mvn clirr:clirr See: INVALID > URI REMOVED > > From: Thomas Andraschko <[email protected]> > To: MyFaces Development <[email protected]> > Date: 09/04/2018 01:28 PM > Subject: Re: 2.3.2 Release > ------------------------------ > > > > AFAIR mvn clirr:clirr > > See: *http://www.mojohaus.org/clirr-maven-plugin/* > <http://www.mojohaus.org/clirr-maven-plugin/> > It checkes the API binary compatibilty > > Am Di., 4. Sep. 2018 um 19:22 Uhr schrieb Paul Nicolucci < > *[email protected]* <[email protected]>>: > > I've got the release ready to go with one exception: > > *https://myfaces.apache.org/core23/release-checklist.html* > <https://myfaces.apache.org/core23/release-checklist.html> > > At the above link it says to do the following: "*Clirr report to check > binary incompatibilities success*" > > Does anyone have any experience in running the Clirr report? > > Thanks for any help you can give. > > Regards, > > Paul Nicolucci > > Dennis Kieselhorst ---08/30/2018 06:47:29 AM---> When I perform the > above operation there is no new tag created in SVN with > the source code > for t > > From: Dennis Kieselhorst <*[email protected]* <[email protected]>> > To: <*[email protected]* <[email protected]>> > Date: 08/30/2018 06:47 AM > Subject: Re: 2.3.2 Release > ------------------------------ > > > > > When I perform the above operation there is no new tag created in > SVN with > > the source code for the 2.3.2 release. Is this now expected since > all of > > our source is in GIT? I just want to ensure that I'm not missing > anything. > > Yes, SVN is no longer involved (only for site publishing). I can see > the tag in Git: > *https://github.com/apache/myfaces/tree/myfaces-core-module-2.3.2* > <https://github.com/apache/myfaces/tree/myfaces-core-module-2.3.2> > > So it looks fine so far... > > Regards > Dennis > > > > > > [attachment "graycol.gif" deleted by Paul Nicolucci/Durham/IBM] > [attachment "graycol.gif" deleted by Paul Nicolucci/Durham/IBM] > > > >
