Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8
Hey Scott - I attempted to do a clean Trinidad build against the new plugins. I happened to notice this exception during the build: [INFO] --- maven-faces-plugin:2.0.8:generate-jsp-taglibs (default) @ trinidad-impl --- [INFO] ClassNotFound error resolving type org.apache.myfaces.trinidad.model.DateListProvider java.lang.ClassNotFoundException: org.apache.myfaces.trinidad.model.DateListProvider at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:86) at org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:47) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractTagGenerator.resolveType(AbstractTagGenerator.java:247) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.TrinidadValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:115) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.writeSetProperties(AbstractValidatorTagGenerator.java:185) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.generateTagHandler(AbstractValidatorTagGenerator.java:62) at org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo._generateTagHandlers(GenerateJspTaglibsMojo.java:794) at org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo.execute(GenerateJspTaglibsMojo.java:104) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) 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:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) [INFO] Generated 145 JSP tag(s) I have no idea whether this exception in new in 2.0.8. Is this something that we should look at before rolling out the plugins release? Andy On Mon, Nov 4, 2013 at 4:29 PM, Scott O'Bryan darkar...@gmail.com wrote: I was running the tasks needed to release the Trinidad Maven Plugins version 2.0.8 which is needed as a prerequisite to a Trinidad release. I have compiled the Release Notes[1] for the 2.0.8 release. I have generated the tag [2] and have deployed the built artifacts to nexus [3]. Lastly I have included a source archive [4]. I've done preliminary testing and building, updated the plugins to comply with checkstyle, and made sure the build passed rat:check. Please take a look at the Trinidad Maven Plugins 2.0.8 release artifacts now and vote. Please note: This vote is majority approval with a minimum of three +1 votes (see [5]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott O'Bryan [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661version=12319290 [2] https
Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8
Andy, Yeah, I was seeing this too. I was trying to track this as part of my work for the next Trinidad release, but I think your right. This may be handled better in the plugin. At the very least we should evaluate it. What's happening here is a new check was added to test if a class for an attribute happens to be an enumeration. In the case where we get the error, DateListProvider hasn't been built yet since the plugins generate the source BEFORE the plugins are built. I'm going to generate a JIRA ticket and I for one think we need to fix this issue before releasing the plugins. As such. my vote is a -1 pending this issue. -- Scott O'Bryan On November 6, 2013 at 7:42:03 AM, Andy Schwartz (andy.g.schwa...@gmail.com) wrote: Hey Scott - I attempted to do a clean Trinidad build against the new plugins. I happened to notice this exception during the build: [INFO] --- maven-faces-plugin:2.0.8:generate-jsp-taglibs (default) @ trinidad-impl --- [INFO] ClassNotFound error resolving type org.apache.myfaces.trinidad.model.DateListProvider java.lang.ClassNotFoundException: org.apache.myfaces.trinidad.model.DateListProvider at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:86) at org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:47) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractTagGenerator.resolveType(AbstractTagGenerator.java:247) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.TrinidadValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:115) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.writeSetProperties(AbstractValidatorTagGenerator.java:185) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.generateTagHandler(AbstractValidatorTagGenerator.java:62) at org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo._generateTagHandlers(GenerateJspTaglibsMojo.java:794) at org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo.execute(GenerateJspTaglibsMojo.java:104) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) 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:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) [INFO] Generated 145 JSP tag(s) I have no idea whether this exception in new in 2.0.8. Is this something that we should look at before rolling out the plugins release? Andy On Mon, Nov 4, 2013 at 4:29 PM, Scott O'Bryan darkar...@gmail.com wrote: I was running the tasks needed to release the Trinidad Maven Plugins version 2.0.8 which is needed as a prerequisite to a Trinidad release. I have compiled the Release Notes[1] for the 2.0.8 release. I have generated the tag [2] and have deployed the built artifacts to nexus
Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8
(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) [INFO] Generated 145 JSP tag(s) I have no idea whether this exception in new in 2.0.8. Is this something that we should look at before rolling out the plugins release? Andy On Mon, Nov 4, 2013 at 4:29 PM, Scott O'Bryan darkar...@gmail.com wrote: I was running the tasks needed to release the Trinidad Maven Plugins version 2.0.8 which is needed as a prerequisite to a Trinidad release. I have compiled the Release Notes[1] for the 2.0.8 release. I have generated the tag [2] and have deployed the built artifacts to nexus [3]. Lastly I have included a source archive [4]. I've done preliminary testing and building, updated the plugins to comply with checkstyle, and made sure the build passed rat:check. Please take a look at the Trinidad Maven Plugins 2.0.8 release artifacts now and vote. Please note: This vote is majority approval with a minimum of three +1 votes (see [5]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott O'Bryan [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661version=12319290 [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.8 [3] https://repository.apache.org/content/repositories/orgapachemyfaces-069 [4] https://repository.apache.org/content/repositories/orgapachemyfaces-069/org/apache/myfaces/trinidadbuild/maven-plugin-parent/2.0.8/maven-plugin-parent-2.0.8-source-release.zip [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8
) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) [INFO] Generated 145 JSP tag(s) I have no idea whether this exception in new in 2.0.8. Is this something that we should look at before rolling out the plugins release? Andy On Mon, Nov 4, 2013 at 4:29 PM, Scott O'Bryan darkar...@gmail.com wrote: I was running the tasks needed to release the Trinidad Maven Plugins version 2.0.8 which is needed as a prerequisite to a Trinidad release. I have compiled the Release Notes[1] for the 2.0.8 release. I have generated the tag [2] and have deployed the built artifacts to nexus [3]. Lastly I have included a source archive [4]. I've done preliminary testing and building, updated the plugins to comply with checkstyle, and made sure the build passed rat:check. Please take a look at the Trinidad Maven Plugins 2.0.8 release artifacts now and vote. Please note: This vote is majority approval with a minimum of three +1 votes (see [5]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott O'Bryan [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661version=12319290 [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.8 [3] https://repository.apache.org/content/repositories/orgapachemyfaces-069 [4] https://repository.apache.org/content/repositories/orgapachemyfaces-069/org/apache/myfaces/trinidadbuild/maven-plugin-parent/2.0.8/maven-plugin-parent-2.0.8-source-release.zip [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8
) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) [INFO] Generated 145 JSP tag(s) I have no idea whether this exception in new in 2.0.8. Is this something that we should look at before rolling out the plugins release? Andy On Mon, Nov 4, 2013 at 4:29 PM, Scott O'Bryan darkar...@gmail.com wrote: I was running the tasks needed to release the Trinidad Maven Plugins version 2.0.8 which is needed as a prerequisite to a Trinidad release. I have compiled the Release Notes[1] for the 2.0.8 release. I have generated the tag [2] and have deployed the built artifacts to nexus [3]. Lastly I have included a source archive [4]. I've done preliminary testing and building, updated the plugins to comply with checkstyle, and made sure the build passed rat:check. Please take a look at the Trinidad Maven Plugins 2.0.8 release artifacts now and vote. Please note: This vote is majority approval with a minimum of three +1 votes (see [5]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott O'Bryan [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661version=12319290 [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.8 [3] https://repository.apache.org/content/repositories/orgapachemyfaces-069 [4] https://repository.apache.org/content/repositories/orgapachemyfaces-069/org/apache/myfaces/trinidadbuild/maven-plugin-parent/2.0.8/maven-plugin-parent-2.0.8-source-release.zip [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8
) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) [INFO] Generated 145 JSP tag(s) I have no idea whether this exception in new in 2.0.8. Is this something that we should look at before rolling out the plugins release? Andy On Mon, Nov 4, 2013 at 4:29 PM, Scott O'Bryan darkar...@gmail.com wrote: I was running the tasks needed to release the Trinidad Maven Plugins version 2.0.8 which is needed as a prerequisite to a Trinidad release. I have compiled the Release Notes[1] for the 2.0.8 release. I have generated the tag [2] and have deployed the built artifacts to nexus [3]. Lastly I have included a source archive [4]. I've done preliminary testing and building, updated the plugins to comply with checkstyle, and made sure the build passed rat:check. Please take a look at the Trinidad Maven Plugins 2.0.8 release artifacts now and vote. Please note: This vote is majority approval with a minimum of three +1 votes (see [5]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott O'Bryan [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661version=12319290 [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.8 [3] https://repository.apache.org/content/repositories/orgapachemyfaces-069 [4] https://repository.apache.org/content/repositories/orgapachemyfaces-069/org/apache/myfaces/trinidadbuild/maven-plugin-parent/2.0.8/maven-plugin-parent-2.0.8-source-release.zip [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
[RESULT] [VOTE] Release of Trinidad Maven Plugins 2.0.8
This vote is now closed and has passed. We have 4 binding +1 votes: Blake Sullivan Andy Schwartz Max Starets Scott O'Bryan Thanks to everyone who voted, I'll prepare the artifacts and the announcement. -- Scott O'Bryan
Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8
) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) [INFO] Generated 145 JSP tag(s) I have no idea whether this exception in new in 2.0.8. Is this something that we should look at before rolling out the plugins release? Andy On Mon, Nov 4, 2013 at 4:29 PM, Scott O'Bryan darkar...@gmail.com wrote: I was running the tasks needed to release the Trinidad Maven Plugins version 2.0.8 which is needed as a prerequisite to a Trinidad release. I have compiled the Release Notes[1] for the 2.0.8 release. I have generated the tag [2] and have deployed the built artifacts to nexus [3]. Lastly I have included a source archive [4]. I've done preliminary testing and building, updated the plugins to comply with checkstyle, and made sure the build passed rat:check. Please take a look at the Trinidad Maven Plugins 2.0.8 release artifacts now and vote. Please note: This vote is majority approval with a minimum of three +1 votes (see [5]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott O'Bryan [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661version=12319290 [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.8 [3] https://repository.apache.org/content/repositories/orgapachemyfaces-069 [4] https://repository.apache.org/content/repositories/orgapachemyfaces-069/org/apache/myfaces/trinidadbuild/maven-plugin-parent/2.0.8/maven-plugin-parent-2.0.8-source-release.zip [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
[VOTE] Release of Trinidad Maven Plugins 2.0.8
I was running the tasks needed to release the Trinidad Maven Plugins version 2.0.8 which is needed as a prerequisite to a Trinidad release. I have compiled the Release Notes[1] for the 2.0.8 release. I have generated the tag [2] and have deployed the built artifacts to nexus [3]. Lastly I have included a source archive [4]. I've done preliminary testing and building, updated the plugins to comply with checkstyle, and made sure the build passed rat:check. Please take a look at the Trinidad Maven Plugins 2.0.8 release artifacts now and vote. Please note: This vote is majority approval with a minimum of three +1 votes (see [5]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott O'Bryan [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661version=12319290 [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.8 [3] https://repository.apache.org/content/repositories/orgapachemyfaces-069 [4] https://repository.apache.org/content/repositories/orgapachemyfaces-069/org/apache/myfaces/trinidadbuild/maven-plugin-parent/2.0.8/maven-plugin-parent-2.0.8-source-release.zip [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
[ANNOUNCE] Release of Apache MyFaces Trinidad Maven Plugins v. 2.0.7
The Apache MyFaces team is please to announce the release of Apache MyFaces Trinidad Maven Plugins v. 2.0.7. Apache MyFaces Trinidad Maven Plugins provide the ability to package translations, automatically create JSF component and renderkit artifacts from meta-data, and provide JDeveloper integration for all maven projects. This release contains several bug fixes and a few improvements to increase the usability of these plugins. They are available in the central maven repository under Group ID org.apache.myfaces.trinidadbuild. Release Notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661version=12317949 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661version=12317949 Thanks, Scott O'Bryan
Result (was: [VOTE] Release of Trinidad Maven Plugins v. 2.0.7)
Thank you all for voting! 4 +1 votes: - Scott O'Bryan - Matt Cooper - Dave Robinson - Nathan Hokanson no 0 or -1 votes. Sincerely, Scott On 12/19/2011 03:54 PM, Scott O'Bryan wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.7 released and now I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins including adding support marking deprecated tag in tag documentation and the removal of some system.out's that made the plugin overly verbose. This tag is needed for the upcoming Trinidad release. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-372/ [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.7
Re: Result (was: [VOTE] Release of Trinidad Maven Plugins v. 2.0.7)
hi scott, thx for releasing it. however, 3 binding votes are required (right now we have 2). regards, gerhard 2011/12/22 Scott O'Bryan darkar...@gmail.com Thank you all for voting! 4 +1 votes: - Scott O'Bryan - Matt Cooper - Dave Robinson - Nathan Hokanson no 0 or -1 votes. Sincerely, Scott On 12/19/2011 03:54 PM, Scott O'Bryan wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.7 released and now I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins including adding support marking deprecated tag in tag documentation and the removal of some system.out's that made the plugin overly verbose. This tag is needed for the upcoming Trinidad release. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-004 https://repository.apache.org/content/repositories/orgapachemyfaces-372/ [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.7https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.6
Re: Result (was: [VOTE] Release of Trinidad Maven Plugins v. 2.0.7)
Gerhard, since when have we started requiring binding votes? Was this new? For releases we decided a long time ago that community support was fine didn't we? On Thu 22 Dec 2011 10:27:18 AM MST, Gerhard Petracek wrote: hi scott, thx for releasing it. however, 3 binding votes are required (right now we have 2). regards, gerhard 2011/12/22 Scott O'Bryan darkar...@gmail.com mailto:darkar...@gmail.com Thank you all for voting! 4 +1 votes: - Scott O'Bryan - Matt Cooper - Dave Robinson - Nathan Hokanson no 0 or -1 votes. Sincerely, Scott On 12/19/2011 03:54 PM, Scott O'Bryan wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.7 released and now I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins including adding support marking deprecated tag in tag documentation and the removal of some system.out's that made the plugin overly verbose. This tag is needed for the upcoming Trinidad release. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-004https://repository.apache.org/content/repositories/orgapachemyfaces-372/ [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.7 https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.6
Re: Result (was: [VOTE] Release of Trinidad Maven Plugins v. 2.0.7)
Good catch Gerhard. I now checked the artifacts and they look ok. So here is my (late) +1 (binding) Scott, others, next time please just ping again on the list if you miss a reviewer of the release as we really need 3 binding +1 _before_ the vote can be closed. Here is a list of the binding apacheIds: http://people.apache.org/committers-by-project.html#myfaces-pmc Guess you know all of this and it just slept through ;) LieGrue, strub From: Gerhard Petracek gpetra...@apache.org To: MyFaces Development dev@myfaces.apache.org Sent: Thursday, December 22, 2011 6:27 PM Subject: Re: Result (was: [VOTE] Release of Trinidad Maven Plugins v. 2.0.7) hi scott, thx for releasing it. however, 3 binding votes are required (right now we have 2). regards, gerhard 2011/12/22 Scott O'Bryan darkar...@gmail.com Thank you all for voting! 4 +1 votes: - Scott O'Bryan - Matt Cooper - Dave Robinson - Nathan Hokanson no 0 or -1 votes. Sincerely, Scott On 12/19/2011 03:54 PM, Scott O'Bryan wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.7 released and now I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins including adding support marking deprecated tag in tag documentation and the removal of some system.out's that made the plugin overly verbose. This tag is needed for the upcoming Trinidad release. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-372/ [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.7
Re: Result (was: [VOTE] Release of Trinidad Maven Plugins v. 2.0.7)
I know we talked about this on the PMC list before and I thought the outcome of that was to not distinguish between binding and non-binding votes for the purposes of releases. I need to look at the Apache rules again, but I didn't think it specified which is why the question came up. :) Or maybe because it's been so long... Scott. Anyway Mark, thanks for the vote. Scott On Thu 22 Dec 2011 10:33:50 AM MST, Mark Struberg wrote: Good catch Gerhard. I now checked the artifacts and they look ok. So here is my (late) +1 (binding) Scott, others, next time please just ping again on the list if you miss a reviewer of the release as we really need 3 binding +1 _before_ the vote can be closed. Here is a list of the binding apacheIds: http://people.apache.org/committers-by-project.html#myfaces-pmc Guess you know all of this and it just slept through ;) LieGrue, strub From: Gerhard Petracekgpetra...@apache.org To: MyFaces Developmentdev@myfaces.apache.org Sent: Thursday, December 22, 2011 6:27 PM Subject: Re: Result (was: [VOTE] Release of Trinidad Maven Plugins v. 2.0.7) hi scott, thx for releasing it. however, 3 binding votes are required (right now we have 2). regards, gerhard 2011/12/22 Scott O'Bryandarkar...@gmail.com Thank you all for voting! 4 +1 votes: - Scott O'Bryan - Matt Cooper - Dave Robinson - Nathan Hokanson no 0 or -1 votes. Sincerely, Scott On 12/19/2011 03:54 PM, Scott O'Bryan wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.7 released and now I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins including adding support marking deprecated tag in tag documentation and the removal of some system.out's that made the plugin overly verbose. This tag is needed for the upcoming Trinidad release. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-372/ [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.7
Re: Result (was: [VOTE] Release of Trinidad Maven Plugins v. 2.0.7)
Scott, I think that's nothing the MyFaces PMC can decide single handedly as it's a general ASF policy: http://www.apache.org/foundation/voting.html Of course we _do_ honour non-binding votes in a few ways. If they are +1 then we are happy to get a release done which is better tested. If there are -1 votes from users, backed with a strong argument or broken use case, then it will for sure cause a discussion and the vote might get abandoned or PMC members will change their vote to -1 as well. LieGrue, strub - Original Message - From: Scott O'Bryan darkar...@gmail.com To: MyFaces Development dev@myfaces.apache.org Cc: Gerhard Petracek gpetra...@apache.org Sent: Thursday, December 22, 2011 6:32 PM Subject: Re: Result (was: [VOTE] Release of Trinidad Maven Plugins v. 2.0.7) G erhard, since when have we started requiring binding votes? Was this new? For releases we decided a long time ago that community support was fine didn't we? On Thu 22 Dec 2011 10:27:18 AM MST, Gerhard Petracek wrote: hi scott, thx for releasing it. however, 3 binding votes are required (right now we have 2). regards, gerhard 2011/12/22 Scott O'Bryan darkar...@gmail.com mailto:darkar...@gmail.com Thank you all for voting! 4 +1 votes: - Scott O'Bryan - Matt Cooper - Dave Robinson - Nathan Hokanson no 0 or -1 votes. Sincerely, Scott On 12/19/2011 03:54 PM, Scott O'Bryan wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.7 released and now I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins including adding support marking deprecated tag in tag documentation and the removal of some system.out's that made the plugin overly verbose. This tag is needed for the upcoming Trinidad release. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-004https://repository.apache.org/content/repositories/orgapachemyfaces-372/ [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.7 https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.6
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.7
+1 On Mon, Dec 19, 2011 at 4:00 PM, Dave Robinson drmaill...@gmail.com wrote: +1 On Mon, Dec 19, 2011 at 3:54 PM, Scott O'Bryan darkar...@gmail.comwrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.7 released and now I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins including adding support marking deprecated tag in tag documentation and the removal of some system.out's that made the plugin overly verbose. This tag is needed for the upcoming Trinidad release. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-004 https://repository.apache.org/content/repositories/orgapachemyfaces-372/ [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.7https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.6
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.7
+1 On Mon, Dec 19, 2011 at 4:00 PM, Dave Robinson drmaill...@gmail.com wrote: +1 On Mon, Dec 19, 2011 at 3:54 PM, Scott O'Bryan darkar...@gmail.comwrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.7 released and now I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins including adding support marking deprecated tag in tag documentation and the removal of some system.out's that made the plugin overly verbose. This tag is needed for the upcoming Trinidad release. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-004 https://repository.apache.org/content/repositories/orgapachemyfaces-372/ [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.7https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.6
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.7
+1 On 12/19/2011 03:54 PM, Scott O'Bryan wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.7 released and now I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins including adding support marking deprecated tag in tag documentation and the removal of some system.out's that made the plugin overly verbose. This tag is needed for the upcoming Trinidad release. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-372/ [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.7
[VOTE] Release of Trinidad Maven Plugins v. 2.0.7
Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.7 released and now I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins including adding support marking deprecated tag in tag documentation and the removal of some system.out's that made the plugin overly verbose. This tag is needed for the upcoming Trinidad release. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-372/ [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.7
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.7
+1 On Mon, Dec 19, 2011 at 3:54 PM, Scott O'Bryan darkar...@gmail.com wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.7 released and now I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins including adding support marking deprecated tag in tag documentation and the removal of some system.out's that made the plugin overly verbose. This tag is needed for the upcoming Trinidad release. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-004 https://repository.apache.org/content/repositories/orgapachemyfaces-372/ [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.7https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.6
[RESULTS] Release of Trinidad Maven Plugins v. 2.0.6
Here are the results of MyFaces plugins [1].. It's been a very busy few weeks - sorry for the delay. +1: Matt Cooper, Scott O'Bryan, Max Starets Thanks for voting, Scott O'Bryan [1] http://mail-archives.apache.org/mod_mbox/myfaces-dev/201108.mbox/%3c4e39a765.4070...@gmail.com%3E
Re: [VOTE[ Release of Trinidad Maven Plugins v. 2.0.6
+1 On Thu, Aug 4, 2011 at 1:45 PM, Scott O'Bryan darkar...@gmail.com wrote: +1 On 08/03/2011 03:43 PM, Max Starets wrote: +1 On 8/3/2011 3:54 PM, Scott O'Bryan wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.6released and now I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins including adding support for more JSF 2.0 stuff as well as support for later versions of JDeveloper and Maven 3. This tag has been in use on Trinidad Trunk for some time and should now be ready for a real release. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/**content/repositories/** orgapachemyfaces-004https://repository.apache.org/content/repositories/orgapachemyfaces-004 [2] https://svn.apache.org/repos/**asf/myfaces/trinidad-maven/** tags/maven-plugin-parent-2.0.6https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.6
Re: [VOTE[ Release of Trinidad Maven Plugins v. 2.0.6
+1 On 08/03/2011 03:43 PM, Max Starets wrote: +1 On 8/3/2011 3:54 PM, Scott O'Bryan wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.6released and now I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins including adding support for more JSF 2.0 stuff as well as support for later versions of JDeveloper and Maven 3. This tag has been in use on Trinidad Trunk for some time and should now be ready for a real release. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-004 [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.6
[VOTE[ Release of Trinidad Maven Plugins v. 2.0.6
Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.6released and now I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins including adding support for more JSF 2.0 stuff as well as support for later versions of JDeveloper and Maven 3. This tag has been in use on Trinidad Trunk for some time and should now be ready for a real release. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-004 [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.6
Re: [VOTE[ Release of Trinidad Maven Plugins v. 2.0.6
+1 On 8/3/2011 3:54 PM, Scott O'Bryan wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.6released and now I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins including adding support for more JSF 2.0 stuff as well as support for later versions of JDeveloper and Maven 3. This tag has been in use on Trinidad Trunk for some time and should now be ready for a real release. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-004 [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.6
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Forgot to vote.. :) +1 On 03/24/2011 10:32 AM, Scott O'Bryan wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.5 released and not I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins now mark the trinidad package as being metadata complete in order to help avoid having to scan the jar for class annotations at runtime. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-035 [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.5
[RESULTS] Release of Trinidad Maven Plugins v. 2.0.5
Hi, Thanks to all the people who voted. We have 5 +1 votes: Max Starets Andy Schwartz Leonardo Uribe Blake Sullivan Scott O'Bryan No +0 or -1 votes. I will now proceed with the release. Scott
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
On Thu, Mar 24, 2011 at 6:06 PM, Leonardo Uribe lu4...@gmail.com wrote: I have created these issues: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-952 Thank you Leonardo! Although we are in between JSRs now, I sent mail to the old jsr-314-open list to see whether we can address this in 2.2: http://lists.jboss.org/pipermail/jsr-314-open-mirror/2011-March/000752.html Andy
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Thanks, Leonardo! You rock! Max On 3/24/2011 6:06 PM, Leonardo Uribe wrote: Hi I have created these issues: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-952 https://issues.apache.org/jira/browse/MYFACES-3082 I agree with the proposed behavior, and I don't think do it could cause any problems. So from my side there is no objections about the artifacts proposed. Thanks for the clarification. Leonardo 2011/3/24 Andy Schwartz andy.g.schwa...@gmail.com: Gang - Looking back at the EG emails, I realize now that I dropped the ball on making sure that my proposed changes actually made it into the spec. Here was my original email (Metadata complete jar files) from Septeber 3, 2009: Gang - Section 11.5.1 of the spec defines the following annotation scanning behavior: Requirements for scanning of classes for annotations * If the faces-config element in the WEB-INF/faces-config.xml file contains metadata-complete attribute whose value is “true”, the implementation must not perform annotation scanning on any classes except for those classes provided by the implementation itself. Otherwise, continue as follows. * If the runtime discovers a conflict between an entry in the Application Configuration Resources and an annotation, the entry in the Application Configuration Resources takes precedence. * All classes in WEB-INF/classes must be scanned. * For every jar in the application's WEB-INF/lib directory, if the jar contains a “META-INF/faces-config.xml” file or a file that matches the regular expression “.*\.faces-config.xml” (even an empty one), all classes in that jar must be scanned. Since application developers have the ability to disable annotation scanning at a global level, this means that any component set that wants to support this mode would need to provide a metadata complete faces-config.xml file. I don't think this is a hardship for most component vendors, since presumably component vendors are going to want to provide design-time metadata (eg. JSR-276 metadata), which, for the moment, requires a faces-config.xml file anyway. A question that came up here is whether we can tweak section 11.5.1 to accommodate metadata complete jar files. That is, can we specify that any jar that contains a faces-config.xml with a metadata-complete=true attribute would not be scanned? This would allow component vendors to indicate that their jar files are metadata complete, and thus avoid the cost of annotation scanning for the contents of the jar. Note that while the annotation scan is typically a one time hit (during application startup), design-time tools may end up starting/stopping JSF repeatedly during the development process. Thus, avoiding unnecessary scanning should provide for a more efficient development experience. Any thoughts on whether we could/should make this change? Does anyone know of reasons why we avoided specifying this originally? Also - if we agree to make this change, is this small enough that we could get this into the the next MR? Andy Both Dan and Pete responded in support. There were no other responses on the EG list. I should have followed up to make sure that the spec update happened, but apparently never did. I will do that now. :-) Sorry about the confusion. :-( Andy
[VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.5 released and not I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins now mark the trinidad package as being metadata complete in order to help avoid having to scan the jar for class annotations at runtime. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-035 [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.5
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
+1 On 3/24/2011 12:32 PM, Scott O'Bryan wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.5 released and not I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins now mark the trinidad package as being metadata complete in order to help avoid having to scan the jar for class annotations at runtime. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-035 [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.5
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
+1. Thanks for putting this together Scott! Andy
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Hi As a side note: SO There were some minor fixes and the plugins now mark the trinidad package SO as being metadata complete in order to help avoid having to scan the jar for SO class annotations at runtime. Reading JSF 2.0 spec, metadata-complete is only used on WEB-INF/faces-config.xml. Is it a change for 2.1? or maybe there is something missing on the spec? regards, Leonardo Uribe 2011/3/24 Andy Schwartz andy.g.schwa...@gmail.com: +1. Thanks for putting this together Scott! Andy
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Hey Leonrado, The change is to allow the plugin to generate metadata-complete=true for trinidad-impl's faces-config.xml. See https://issues.apache.org/jira/browse/TRINIDAD-2068 Max On 3/24/2011 3:50 PM, Leonardo Uribe wrote: Hi As a side note: SO There were some minor fixes and the plugins now mark the trinidad package SO as being metadata complete in order to help avoid having to scan the jar for SO class annotations at runtime. Reading JSF 2.0 spec, metadata-complete is only used on WEB-INF/faces-config.xml. Is it a change for 2.1? or maybe there is something missing on the spec? regards, Leonardo Uribe 2011/3/24 Andy Schwartz andy.g.schwa...@gmail.com: +1. Thanks for putting this together Scott! Andy
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
+1 -- Blake Sullivan On 3/24/11 9:32 AM, Scott O'Bryan wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.5 released and not I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins now mark the trinidad package as being metadata complete in order to help avoid having to scan the jar for class annotations at runtime. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-035 [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.5
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Hi 2011/3/24 Max Starets max.star...@oracle.com: Hey Leonrado, The change is to allow the plugin to generate metadata-complete=true for trinidad-impl's faces-config.xml. See https://issues.apache.org/jira/browse/TRINIDAD-2068 The problem here is this config will be ignored by myfaces core, because we don't have any code that check for it before scan for annotations. In practice, trinidad jars are scanned for JSF 2.0 annotations, no matter if myfaces or mojarra are used. I understand the intention, but to complete it, it is necessary to commit some changes on myfaces core 2.0.x (and mojarra). I checked it some days ago and the documentation is not clear: ...The metadata-complete attribute defines whether this JavaServer Faces application is complete, or whether the class files available to this module and packaged with this application should be examined for annotations that specify configuration information ... This attribute is only inspected on the application configuration resource file located at WEB-INF/faces-config.xml. The presence of this attribute on any application configuration resource other than the one located at WEB-INF/faces-config.xml, including any files named using the javax.faces.CONFIG_FILES attribute, must be ignored. ... regards, Leonardo Max On 3/24/2011 3:50 PM, Leonardo Uribe wrote: Hi As a side note: SO There were some minor fixes and the plugins now mark the trinidad package SO as being metadata complete in order to help avoid having to scan the jar for SO class annotations at runtime. Reading JSF 2.0 spec, metadata-complete is only used on WEB-INF/faces-config.xml. Is it a change for 2.1? or maybe there is something missing on the spec? regards, Leonardo Uribe 2011/3/24 Andy Schwartz andy.g.schwa...@gmail.com: +1. Thanks for putting this together Scott! Andy
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Well there ya go. Thanks for commenting Leonardo. I did not know that.. :D Is this going to be a showstopper for the release or (since it's ignored) are people okay with having it in our FacesConfig for now? I personally think it can't hurt but the spec does seem pretty clear on the subject. On 03/24/2011 03:13 PM, Leonardo Uribe wrote: Hi 2011/3/24 Max Staretsmax.star...@oracle.com: Hey Leonrado, The change is to allow the plugin to generate metadata-complete=true for trinidad-impl's faces-config.xml. See https://issues.apache.org/jira/browse/TRINIDAD-2068 The problem here is this config will be ignored by myfaces core, because we don't have any code that check for it before scan for annotations. In practice, trinidad jars are scanned for JSF 2.0 annotations, no matter if myfaces or mojarra are used. I understand the intention, but to complete it, it is necessary to commit some changes on myfaces core 2.0.x (and mojarra). I checked it some days ago and the documentation is not clear: ...The metadata-complete attribute defines whether this JavaServer Faces application is complete, or whether the class files available to this module and packaged with this application should be examined for annotations that specify configuration information ... This attribute is only inspected on the application configuration resource file located at WEB-INF/faces-config.xml. The presence of this attribute on any application configuration resource other than the one located at WEB-INF/faces-config.xml, including any files named using the javax.faces.CONFIG_FILES attribute, must be ignored. ... regards, Leonardo Max On 3/24/2011 3:50 PM, Leonardo Uribe wrote: Hi As a side note: SO There were some minor fixes and the plugins now mark the trinidad package SO as being metadata complete in order to help avoid having to scan the jar for SO class annotations at runtime. Reading JSF 2.0 spec, metadata-complete is only used on WEB-INF/faces-config.xml. Is it a change for 2.1? or maybe there is something missing on the spec? regards, Leonardo Uribe 2011/3/24 Andy Schwartzandy.g.schwa...@gmail.com: +1. Thanks for putting this together Scott! Andy
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Leonardo, I have tested metadata-complete with Mojarra, and it is not ignored. I can point you to the Mojarra code that does the check. From what I understand, this feature was included a while ago (during the initial 2.0 release) after Andy Schwartz lobbied for it. It looks like the spec was not properly updated, I still would like to proceed with the plugin change since we can take advantage of skipping annotation scanning at least with Mojarra. Max On 3/24/2011 5:13 PM, Leonardo Uribe wrote: Hi 2011/3/24 Max Starets max.star...@oracle.com: Hey Leonrado, The change is to allow the plugin to generate metadata-complete=true for trinidad-impl's faces-config.xml. See https://issues.apache.org/jira/browse/TRINIDAD-2068 The problem here is this config will be ignored by myfaces core, because we don't have any code that check for it before scan for annotations. In practice, trinidad jars are scanned for JSF 2.0 annotations, no matter if myfaces or mojarra are used. I understand the intention, but to complete it, it is necessary to commit some changes on myfaces core 2.0.x (and mojarra). I checked it some days ago and the documentation is not clear: ...The metadata-complete attribute defines whether this JavaServer Faces application is complete, or whether the class files available to this module and packaged with this application should be examined for annotations that specify configuration information ... This attribute is only inspected on the application configuration resource file located at WEB-INF/faces-config.xml. The presence of this attribute on any application configuration resource other than the one located at WEB-INF/faces-config.xml, including any files named using the javax.faces.CONFIG_FILES attribute, must be ignored. ... regards, Leonardo Max On 3/24/2011 3:50 PM, Leonardo Uribe wrote: Hi As a side note: SO There were some minor fixes and the plugins now mark the trinidad package SO as being metadata complete in order to help avoid having to scan the jar for SO class annotations at runtime. Reading JSF 2.0 spec, metadata-complete is only used on WEB-INF/faces-config.xml. Is it a change for 2.1? or maybe there is something missing on the spec? regards, Leonardo Uribe 2011/3/24 Andy Schwartz andy.g.schwa...@gmail.com: +1. Thanks for putting this together Scott! Andy
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Leonardo, The check in Mojarra is done in com.sun.faces.config.ConfigManager.getAnnotationScanURLs(). Andy can probably dig out EG e-mails where this was agreed. Thanks, Max On 3/24/2011 5:35 PM, Max Starets wrote: Leonardo, I have tested metadata-complete with Mojarra, and it is not ignored. I can point you to the Mojarra code that does the check. From what I understand, this feature was included a while ago (during the initial 2.0 release) after Andy Schwartz lobbied for it. It looks like the spec was not properly updated, I still would like to proceed with the plugin change since we can take advantage of skipping annotation scanning at least with Mojarra. Max On 3/24/2011 5:13 PM, Leonardo Uribe wrote: Hi 2011/3/24 Max Starets max.star...@oracle.com: Hey Leonrado, The change is to allow the plugin to generate metadata-complete=true for trinidad-impl's faces-config.xml. See https://issues.apache.org/jira/browse/TRINIDAD-2068 The problem here is this config will be ignored by myfaces core, because we don't have any code that check for it before scan for annotations. In practice, trinidad jars are scanned for JSF 2.0 annotations, no matter if myfaces or mojarra are used. I understand the intention, but to complete it, it is necessary to commit some changes on myfaces core 2.0.x (and mojarra). I checked it some days ago and the documentation is not clear: ...The metadata-complete attribute defines whether this JavaServer Faces application is complete, or whether the class files available to this module and packaged with this application should be examined for annotations that specify configuration information ... This attribute is only inspected on the application configuration resource file located at WEB-INF/faces-config.xml. The presence of this attribute on any application configuration resource other than the one located at WEB-INF/faces-config.xml, including any files named using the javax.faces.CONFIG_FILES attribute, must be ignored. ... regards, Leonardo Max On 3/24/2011 3:50 PM, Leonardo Uribe wrote: Hi As a side note: SO There were some minor fixes and the plugins now mark the trinidad package SO as being metadata complete in order to help avoid having to scan the jar for SO class annotations at runtime. Reading JSF 2.0 spec, metadata-complete is only used on WEB-INF/faces-config.xml. Is it a change for 2.1? or maybe there is something missing on the spec? regards, Leonardo Uribe 2011/3/24 Andy Schwartz andy.g.schwa...@gmail.com: +1. Thanks for putting this together Scott! Andy
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
I, for one, am all for having it in. It's not like it will break anything and if it gives a performance boost, all the better. Max, we may want to generate a bug against the spec to see if they can fix that. Is that possible? On Mar 24, 2011, at 3:49 PM, Max Starets max.star...@oracle.com wrote: Leonardo, The check in Mojarra is done in com.sun.faces.config.ConfigManager.getAnnotationScanURLs(). Andy can probably dig out EG e-mails where this was agreed. Thanks, Max On 3/24/2011 5:35 PM, Max Starets wrote: Leonardo, I have tested metadata-complete with Mojarra, and it is not ignored. I can point you to the Mojarra code that does the check. From what I understand, this feature was included a while ago (during the initial 2.0 release) after Andy Schwartz lobbied for it. It looks like the spec was not properly updated, I still would like to proceed with the plugin change since we can take advantage of skipping annotation scanning at least with Mojarra. Max On 3/24/2011 5:13 PM, Leonardo Uribe wrote: Hi 2011/3/24 Max Starets max.star...@oracle.com max.star...@oracle.com: Hey Leonrado, The change is to allow the plugin to generate metadata-complete=true for trinidad-impl's faces-config.xml. See https://issues.apache.org/jira/browse/TRINIDAD-2068 The problem here is this config will be ignored by myfaces core, because we don't have any code that check for it before scan for annotations. In practice, trinidad jars are scanned for JSF 2.0 annotations, no matter if myfaces or mojarra are used. I understand the intention, but to complete it, it is necessary to commit some changes on myfaces core 2.0.x (and mojarra). I checked it some days ago and the documentation is not clear: ...The metadata-complete attribute defines whether this JavaServer Faces application is complete, or whether the class files available to this module and packaged with this application should be examined for annotations that specify configuration information ... This attribute is only inspected on the application configuration resource file located at WEB-INF/faces-config.xml. The presence of this attribute on any application configuration resource other than the one located at WEB-INF/faces-config.xml, including any files named using the javax.faces.CONFIG_FILES attribute, must be ignored. ... regards, Leonardo Max On 3/24/2011 3:50 PM, Leonardo Uribe wrote: Hi As a side note: SO There were some minor fixes and the plugins now mark the trinidad package SO as being metadata complete in order to help avoid having to scan the jar for SO class annotations at runtime. Reading JSF 2.0 spec, metadata-complete is only used on WEB-INF/faces-config.xml. Is it a change for 2.1? or maybe there is something missing on the spec? regards, Leonardo Uribe 2011/3/24 Andy Schwartz andy.g.schwa...@gmail.com andy.g.schwa...@gmail.com: +1. Thanks for putting this together Scott! Andy
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Gang - Looking back at the EG emails, I realize now that I dropped the ball on making sure that my proposed changes actually made it into the spec. Here was my original email (Metadata complete jar files) from Septeber 3, 2009: Gang - Section 11.5.1 of the spec defines the following annotation scanning behavior: Requirements for scanning of classes for annotations * If the faces-config element in the WEB-INF/faces-config.xml file contains metadata-complete attribute whose value is “true”, the implementation must not perform annotation scanning on any classes except for those classes provided by the implementation itself. Otherwise, continue as follows. * If the runtime discovers a conflict between an entry in the Application Configuration Resources and an annotation, the entry in the Application Configuration Resources takes precedence. * All classes in WEB-INF/classes must be scanned. * For every jar in the application's WEB-INF/lib directory, if the jar contains a “META-INF/faces-config.xml” file or a file that matches the regular expression “.*\.faces-config.xml” (even an empty one), all classes in that jar must be scanned. Since application developers have the ability to disable annotation scanning at a global level, this means that any component set that wants to support this mode would need to provide a metadata complete faces-config.xml file. I don't think this is a hardship for most component vendors, since presumably component vendors are going to want to provide design-time metadata (eg. JSR-276 metadata), which, for the moment, requires a faces-config.xml file anyway. A question that came up here is whether we can tweak section 11.5.1 to accommodate metadata complete jar files. That is, can we specify that any jar that contains a faces-config.xml with a metadata-complete=true attribute would not be scanned? This would allow component vendors to indicate that their jar files are metadata complete, and thus avoid the cost of annotation scanning for the contents of the jar. Note that while the annotation scan is typically a one time hit (during application startup), design-time tools may end up starting/stopping JSF repeatedly during the development process. Thus, avoiding unnecessary scanning should provide for a more efficient development experience. Any thoughts on whether we could/should make this change? Does anyone know of reasons why we avoided specifying this originally? Also - if we agree to make this change, is this small enough that we could get this into the the next MR? Andy Both Dan and Pete responded in support. There were no other responses on the EG list. I should have followed up to make sure that the spec update happened, but apparently never did. I will do that now. :-) Sorry about the confusion. :-( Andy
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Hi I have created these issues: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-952 https://issues.apache.org/jira/browse/MYFACES-3082 I agree with the proposed behavior, and I don't think do it could cause any problems. So from my side there is no objections about the artifacts proposed. Thanks for the clarification. Leonardo 2011/3/24 Andy Schwartz andy.g.schwa...@gmail.com: Gang - Looking back at the EG emails, I realize now that I dropped the ball on making sure that my proposed changes actually made it into the spec. Here was my original email (Metadata complete jar files) from Septeber 3, 2009: Gang - Section 11.5.1 of the spec defines the following annotation scanning behavior: Requirements for scanning of classes for annotations * If the faces-config element in the WEB-INF/faces-config.xml file contains metadata-complete attribute whose value is “true”, the implementation must not perform annotation scanning on any classes except for those classes provided by the implementation itself. Otherwise, continue as follows. * If the runtime discovers a conflict between an entry in the Application Configuration Resources and an annotation, the entry in the Application Configuration Resources takes precedence. * All classes in WEB-INF/classes must be scanned. * For every jar in the application's WEB-INF/lib directory, if the jar contains a “META-INF/faces-config.xml” file or a file that matches the regular expression “.*\.faces-config.xml” (even an empty one), all classes in that jar must be scanned. Since application developers have the ability to disable annotation scanning at a global level, this means that any component set that wants to support this mode would need to provide a metadata complete faces-config.xml file. I don't think this is a hardship for most component vendors, since presumably component vendors are going to want to provide design-time metadata (eg. JSR-276 metadata), which, for the moment, requires a faces-config.xml file anyway. A question that came up here is whether we can tweak section 11.5.1 to accommodate metadata complete jar files. That is, can we specify that any jar that contains a faces-config.xml with a metadata-complete=true attribute would not be scanned? This would allow component vendors to indicate that their jar files are metadata complete, and thus avoid the cost of annotation scanning for the contents of the jar. Note that while the annotation scan is typically a one time hit (during application startup), design-time tools may end up starting/stopping JSF repeatedly during the development process. Thus, avoiding unnecessary scanning should provide for a more efficient development experience. Any thoughts on whether we could/should make this change? Does anyone know of reasons why we avoided specifying this originally? Also - if we agree to make this change, is this small enough that we could get this into the the next MR? Andy Both Dan and Pete responded in support. There were no other responses on the EG list. I should have followed up to make sure that the spec update happened, but apparently never did. I will do that now. :-) Sorry about the confusion. :-( Andy
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Hey Andy, I'm wondering if there should be a TCK check for this as well since the behavior has come into question. Scott On 03/24/2011 03:57 PM, Andy Schwartz wrote: Gang - Looking back at the EG emails, I realize now that I dropped the ball on making sure that my proposed changes actually made it into the spec. Here was my original email (Metadata complete jar files) from Septeber 3, 2009: Gang - Section 11.5.1 of the spec defines the following annotation scanning behavior: Requirements for scanning of classes for annotations * If thefaces-config element in the WEB-INF/faces-config.xml file contains metadata-complete attribute whose value is “true”, the implementation must not perform annotation scanning on any classes except for those classes provided by the implementation itself. Otherwise, continue as follows. * If the runtime discovers a conflict between an entry in the Application Configuration Resources and an annotation, the entry in the Application Configuration Resources takes precedence. * All classes in WEB-INF/classes must be scanned. * For every jar in the application's WEB-INF/lib directory, if the jar contains a “META-INF/faces-config.xml” file or a file that matches the regular expression “.*\.faces-config.xml” (even an empty one), all classes in that jar must be scanned. Since application developers have the ability to disable annotation scanning at a global level, this means that any component set that wants to support this mode would need to provide a metadata complete faces-config.xml file. I don't think this is a hardship for most component vendors, since presumably component vendors are going to want to provide design-time metadata (eg. JSR-276 metadata), which, for the moment, requires a faces-config.xml file anyway. A question that came up here is whether we can tweak section 11.5.1 to accommodate metadata complete jar files. That is, can we specify that any jar that contains a faces-config.xml with a metadata-complete=true attribute would not be scanned? This would allow component vendors to indicate that their jar files are metadata complete, and thus avoid the cost of annotation scanning for the contents of the jar. Note that while the annotation scan is typically a one time hit (during application startup), design-time tools may end up starting/stopping JSF repeatedly during the development process. Thus, avoiding unnecessary scanning should provide for a more efficient development experience. Any thoughts on whether we could/should make this change? Does anyone know of reasons why we avoided specifying this originally? Also - if we agree to make this change, is this small enough that we could get this into the the next MR? Andy Both Dan and Pete responded in support. There were no other responses on the EG list. I should have followed up to make sure that the spec update happened, but apparently never did. I will do that now. :-) Sorry about the confusion. :-( Andy
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Is that a +1? :D On Mar 24, 2011, at 4:06 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi I have created these issues: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-952 https://issues.apache.org/jira/browse/MYFACES-3082 I agree with the proposed behavior, and I don't think do it could cause any problems. So from my side there is no objections about the artifacts proposed. Thanks for the clarification. Leonardo 2011/3/24 Andy Schwartz andy.g.schwa...@gmail.com: Gang - Looking back at the EG emails, I realize now that I dropped the ball on making sure that my proposed changes actually made it into the spec. Here was my original email (Metadata complete jar files) from Septeber 3, 2009: Gang - Section 11.5.1 of the spec defines the following annotation scanning behavior: Requirements for scanning of classes for annotations * If the faces-config element in the WEB-INF/faces-config.xml file contains metadata-complete attribute whose value is “true”, the implementation must not perform annotation scanning on any classes except for those classes provided by the implementation itself. Otherwise, continue as follows. * If the runtime discovers a conflict between an entry in the Application Configuration Resources and an annotation, the entry in the Application Configuration Resources takes precedence. * All classes in WEB-INF/classes must be scanned. * For every jar in the application's WEB-INF/lib directory, if the jar contains a “META-INF/faces-config.xml” file or a file that matches the regular expression “.*\.faces-config.xml” (even an empty one), all classes in that jar must be scanned. Since application developers have the ability to disable annotation scanning at a global level, this means that any component set that wants to support this mode would need to provide a metadata complete faces-config.xml file. I don't think this is a hardship for most component vendors, since presumably component vendors are going to want to provide design-time metadata (eg. JSR-276 metadata), which, for the moment, requires a faces-config.xml file anyway. A question that came up here is whether we can tweak section 11.5.1 to accommodate metadata complete jar files. That is, can we specify that any jar that contains a faces-config.xml with a metadata-complete=true attribute would not be scanned? This would allow component vendors to indicate that their jar files are metadata complete, and thus avoid the cost of annotation scanning for the contents of the jar. Note that while the annotation scan is typically a one time hit (during application startup), design-time tools may end up starting/stopping JSF repeatedly during the development process. Thus, avoiding unnecessary scanning should provide for a more efficient development experience. Any thoughts on whether we could/should make this change? Does anyone know of reasons why we avoided specifying this originally? Also - if we agree to make this change, is this small enough that we could get this into the the next MR? Andy Both Dan and Pete responded in support. There were no other responses on the EG list. I should have followed up to make sure that the spec update happened, but apparently never did. I will do that now. :-) Sorry about the confusion. :-( Andy
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
+1 2011/3/24 Scott O'Bryan darkar...@gmail.com: Is that a +1? :D On Mar 24, 2011, at 4:06 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi I have created these issues: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-952 https://issues.apache.org/jira/browse/MYFACES-3082 I agree with the proposed behavior, and I don't think do it could cause any problems. So from my side there is no objections about the artifacts proposed. Thanks for the clarification. Leonardo 2011/3/24 Andy Schwartz andy.g.schwa...@gmail.com: Gang - Looking back at the EG emails, I realize now that I dropped the ball on making sure that my proposed changes actually made it into the spec. Here was my original email (Metadata complete jar files) from Septeber 3, 2009: Gang - Section 11.5.1 of the spec defines the following annotation scanning behavior: Requirements for scanning of classes for annotations * If the faces-config element in the WEB-INF/faces-config.xml file contains metadata-complete attribute whose value is “true”, the implementation must not perform annotation scanning on any classes except for those classes provided by the implementation itself. Otherwise, continue as follows. * If the runtime discovers a conflict between an entry in the Application Configuration Resources and an annotation, the entry in the Application Configuration Resources takes precedence. * All classes in WEB-INF/classes must be scanned. * For every jar in the application's WEB-INF/lib directory, if the jar contains a “META-INF/faces-config.xml” file or a file that matches the regular expression “.*\.faces-config.xml” (even an empty one), all classes in that jar must be scanned. Since application developers have the ability to disable annotation scanning at a global level, this means that any component set that wants to support this mode would need to provide a metadata complete faces-config.xml file. I don't think this is a hardship for most component vendors, since presumably component vendors are going to want to provide design-time metadata (eg. JSR-276 metadata), which, for the moment, requires a faces-config.xml file anyway. A question that came up here is whether we can tweak section 11.5.1 to accommodate metadata complete jar files. That is, can we specify that any jar that contains a faces-config.xml with a metadata-complete=true attribute would not be scanned? This would allow component vendors to indicate that their jar files are metadata complete, and thus avoid the cost of annotation scanning for the contents of the jar. Note that while the annotation scan is typically a one time hit (during application startup), design-time tools may end up starting/stopping JSF repeatedly during the development process. Thus, avoiding unnecessary scanning should provide for a more efficient development experience. Any thoughts on whether we could/should make this change? Does anyone know of reasons why we avoided specifying this originally? Also - if we agree to make this change, is this small enough that we could get this into the the next MR? Andy Both Dan and Pete responded in support. There were no other responses on the EG list. I should have followed up to make sure that the spec update happened, but apparently never did. I will do that now. :-) Sorry about the confusion. :-( Andy
Re: [Trinidad] maven plugins
+1 Jeanne Waldman wrote: +1 Matthias Wessendorf wrote, On 4/2/2010 1:58 AM PT: Hi, currently the work for JSF2 (and Trinidad2) is on a branch, since Trinidad2 (JSF2-based) is now trunk, I feel that we should make the 2.0-specific maven work trunk and the current trunk will be a branch. Any concerns? -Matthias
[Trinidad] maven plugins
Hi, currently the work for JSF2 (and Trinidad2) is on a branch, since Trinidad2 (JSF2-based) is now trunk, I feel that we should make the 2.0-specific maven work trunk and the current trunk will be a branch. Any concerns? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad] maven plugins
+1 Matthias Wessendorf wrote, On 4/2/2010 1:58 AM PT: Hi, currently the work for JSF2 (and Trinidad2) is on a branch, since Trinidad2 (JSF2-based) is now trunk, I feel that we should make the 2.0-specific maven work trunk and the current trunk will be a branch. Any concerns? -Matthias
Re: [Trinidad] Maven Plugins
ok... looks like myfaces-build-tools won the race. structure will be /myfaces-build-tools -/maven2-plugins -/all the current (trin) plugins -tbc -M On Dec 15, 2007 11:12 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, there is this maven plugins folder for the Trinidad Plugins (see [1]). The Trinidad inside the name may confuse people. The plugins are generally usable outside of Trinidad as well. The maven-faces-plugin for instance, is used in other projects, such as MyFaces Core, or MyFaces Commons. The idea is to move them into a different location. A name like myfaces developers toolkit, myfaces dev tools, or what ever you like ? The idea would be to keep it abstract like /myfaces-dev-tools -/maven2-plugins -tbc that would allow us to have maven3 or ant or what ever support as well. Greetings, Matze Manfred [1] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk/ -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Trinidad] Maven Plugins
Did a relocate of the plugins to: https://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/trunk/maven2-plugins/ the current trinidad-pluings are still in their trinidad-maven trunk; I renamed the plugins to be compliant to the naming-schema maven-blah-plugin means that blah is a plugin from the maven folks; they are now named: myfaces-whatever-plugin (like myfaces-jdev-plugin) Need to work on the groupIds, the java packages etc. Nice task for between the years :-) On Dec 20, 2007 11:28 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: ok... looks like myfaces-build-tools won the race. structure will be /myfaces-build-tools -/maven2-plugins -/all the current (trin) plugins -tbc -M On Dec 15, 2007 11:12 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, there is this maven plugins folder for the Trinidad Plugins (see [1]). The Trinidad inside the name may confuse people. The plugins are generally usable outside of Trinidad as well. The maven-faces-plugin for instance, is used in other projects, such as MyFaces Core, or MyFaces Commons. The idea is to move them into a different location. A name like myfaces developers toolkit, myfaces dev tools, or what ever you like ? The idea would be to keep it abstract like /myfaces-dev-tools -/maven2-plugins -tbc that would allow us to have maven3 or ant or what ever support as well. Greetings, Matze Manfred [1] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk/ -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Trinidad] Maven Plugins
Thanks for the build-tools stuff Matthias. That's a very nice tidyup. Having myfaces-core depend on stuff called trinidad was rather confusing... Matthias Wessendorf [EMAIL PROTECTED] schrieb: Did a relocate of the plugins to: https://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/trunk/maven2-plugins/ the current trinidad-pluings are still in their trinidad-maven trunk; I renamed the plugins to be compliant to the naming-schema maven-blah-plugin means that blah is a plugin from the maven folks; they are now named: myfaces-whatever-plugin (like myfaces-jdev-plugin) Need to work on the groupIds, the java packages etc. Nice task for between the years :-) On Dec 20, 2007 11:28 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: ok... looks like myfaces-build-tools won the race. structure will be /myfaces-build-tools -/maven2-plugins -/all the current (trin) plugins -tbc -M On Dec 15, 2007 11:12 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, there is this maven plugins folder for the Trinidad Plugins (see [1]). The Trinidad inside the name may confuse people. The plugins are generally usable outside of Trinidad as well. The maven-faces-plugin for instance, is used in other projects, such as MyFaces Core, or MyFaces Commons. The idea is to move them into a different location. A name like myfaces developers toolkit, myfaces dev tools, or what ever you like ? The idea would be to keep it abstract like /myfaces-dev-tools -/maven2-plugins -tbc that would allow us to have maven3 or ant or what ever support as well. Greetings, Matze Manfred [1] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk/ -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Trinidad] Maven Plugins
no other comments ? that would mean to me, everbody is fine w/ the change. -M On Dec 16, 2007 3:29 PM, Manfred Geiler [EMAIL PROTECTED] wrote: yes, myfaces-build-tools is a much better name --Manfred On 12/16/07, Bruno Aranda [EMAIL PROTECTED] wrote: +1 About the naming, though, this seems to be more myfaces-build-tools than myfaces-dev-tools, because as far as I understand, this artifacts are used during the build, not for just development... Thanks for the good work! Bruno On 15/12/2007, Matthias Wessendorf [EMAIL PROTECTED] wrote: Bernd's wagon could be also hosted there as well. -M On Dec 15, 2007 11:12 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, there is this maven plugins folder for the Trinidad Plugins (see [1]). The Trinidad inside the name may confuse people. The plugins are generally usable outside of Trinidad as well. The maven-faces-plugin for instance, is used in other projects, such as MyFaces Core, or MyFaces Commons. The idea is to move them into a different location. A name like myfaces developers toolkit, myfaces dev tools, or what ever you like ? The idea would be to keep it abstract like /myfaces-dev-tools -/maven2-plugins -tbc that would allow us to have maven3 or ant or what ever support as well. Greetings, Matze Manfred [1] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk/ -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Trinidad] Maven Plugins
yes, myfaces-build-tools is a much better name --Manfred On 12/16/07, Bruno Aranda [EMAIL PROTECTED] wrote: +1 About the naming, though, this seems to be more myfaces-build-tools than myfaces-dev-tools, because as far as I understand, this artifacts are used during the build, not for just development... Thanks for the good work! Bruno On 15/12/2007, Matthias Wessendorf [EMAIL PROTECTED] wrote: Bernd's wagon could be also hosted there as well. -M On Dec 15, 2007 11:12 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, there is this maven plugins folder for the Trinidad Plugins (see [1]). The Trinidad inside the name may confuse people. The plugins are generally usable outside of Trinidad as well. The maven-faces-plugin for instance, is used in other projects, such as MyFaces Core, or MyFaces Commons. The idea is to move them into a different location. A name like myfaces developers toolkit, myfaces dev tools, or what ever you like ? The idea would be to keep it abstract like /myfaces-dev-tools -/maven2-plugins -tbc that would allow us to have maven3 or ant or what ever support as well. Greetings, Matze Manfred [1] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk/ -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[Trinidad] Maven Plugins
Hi, there is this maven plugins folder for the Trinidad Plugins (see [1]). The Trinidad inside the name may confuse people. The plugins are generally usable outside of Trinidad as well. The maven-faces-plugin for instance, is used in other projects, such as MyFaces Core, or MyFaces Commons. The idea is to move them into a different location. A name like myfaces developers toolkit, myfaces dev tools, or what ever you like ? The idea would be to keep it abstract like /myfaces-dev-tools -/maven2-plugins -tbc that would allow us to have maven3 or ant or what ever support as well. Greetings, Matze Manfred [1] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk/ -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Trinidad] Maven Plugins
Bernd's wagon could be also hosted there as well. -M On Dec 15, 2007 11:12 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, there is this maven plugins folder for the Trinidad Plugins (see [1]). The Trinidad inside the name may confuse people. The plugins are generally usable outside of Trinidad as well. The maven-faces-plugin for instance, is used in other projects, such as MyFaces Core, or MyFaces Commons. The idea is to move them into a different location. A name like myfaces developers toolkit, myfaces dev tools, or what ever you like ? The idea would be to keep it abstract like /myfaces-dev-tools -/maven2-plugins -tbc that would allow us to have maven3 or ant or what ever support as well. Greetings, Matze Manfred [1] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk/ -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Trinidad] Maven Plugins
+1 About the naming, though, this seems to be more myfaces-build-tools than myfaces-dev-tools, because as far as I understand, this artifacts are used during the build, not for just development... Thanks for the good work! Bruno On 15/12/2007, Matthias Wessendorf [EMAIL PROTECTED] wrote: Bernd's wagon could be also hosted there as well. -M On Dec 15, 2007 11:12 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, there is this maven plugins folder for the Trinidad Plugins (see [1]). The Trinidad inside the name may confuse people. The plugins are generally usable outside of Trinidad as well. The maven-faces-plugin for instance, is used in other projects, such as MyFaces Core, or MyFaces Commons. The idea is to move them into a different location. A name like myfaces developers toolkit, myfaces dev tools, or what ever you like ? The idea would be to keep it abstract like /myfaces-dev-tools -/maven2-plugins -tbc that would allow us to have maven3 or ant or what ever support as well. Greetings, Matze Manfred [1] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk/ -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
