[JBoss JIRA] (RF-13616) PopupPanel autosize with togglePanel doesn't resize
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13616?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13616:
-------------------------------
Description:
PopupPanel doesn't autosize correctly after move. Moving a PopupPanel with 'autosized' attribute enabled causes the width properties of its inner container div, content div, srcoller div, and shadow div to be hard-set such that a subsequent content change doesn't trigger the auto-resize of the PopupPanel any longer. The PopupPanel height is apparently unaffected.
Attached is a testcase to demonstrate the problem, see the attached zip file containing a minimal JSF application which reproduces the undesired behavior.
{code}
<ui:define name="body"
onload="#{rich:component('popup')}.hide(); return false;">
<h:outputStylesheet>
.rf-tgp-itm {
border: 1px solid #{richSkin.panelBorderColor};
padding: 5px;
}
.tabDiv {
margin: 0 5px 5px 0;
border: 1px solid #{richSkin.panelBorderColor};
background-color: #{richSkin.headerBackgroundColor};
cursor: pointer;
padding: 0 5px;
float: left;
}
</h:outputStylesheet>
<h:form>
<h:commandButton value="Open the popup">
<rich:componentControl target="popup" operation="show" />
</h:commandButton>
</h:form>
<rich:popupPanel id="popup" modal="false" autosized="true"
resizeable="false">
<f:facet name="header">
<h:outputText value="Demo PopupPanel" />
</f:facet>
<f:facet name="controls">
<h:outputLink value="#"
onclick="#{rich:component('popup')}.hide(); return false;">X</h:outputLink>
</f:facet>
<h:form>
<rich:togglePanel id="panel1" activeItem="item1" render="tabs"
itemChangeListener="#{panelMenuBean.processItemChange}">
<rich:togglePanelItem name="item1">
<h3>Panel Item 1</h3>
<p>Steps to reproduce:</p>
<p>1. Without moving the PopupPanel directly switch to Panel
Item 2.</p>
<p>3. Now move the PopupPanel around and then switch back to
Panel Item 2.</p>
</rich:togglePanelItem>
<rich:togglePanelItem name="item2" style="width:777px">
<h3>Panel Item 2</h3>
<p>2. The PopupPanel is autosized, correctly adjusting to the
size difference between its previous and its current content. Now
switch back to Panel Item 1.</p>
<p>4. As you notice, the PopupPanel isn't properly autosized
anymore after first moving it but is now stuck to the smaller
width of Panel Item 1, its previous content.</p>
</rich:togglePanelItem>
</rich:togglePanel>
<a4j:outputPanel id="tabs" layout="block">
<a4j:outputPanel layout="block" styleClass="tabDiv">
<rich:toggleControl event="click" targetPanel="panel1"
targetItem="item1" />
<h:outputText value="Toggle Panel Item 1"
style="#{rich:findComponent('panel1').activeItem == 'item1' ? 'font-weight:bold' : 'font-weight:normal'}" />
</a4j:outputPanel>
<a4j:outputPanel layout="block" styleClass="tabDiv">
<rich:toggleControl event="click" targetPanel="panel1"
targetItem="item2" />
<h:outputText value="Toggle Panel Item 2"
style="#{rich:findComponent('panel1').activeItem == 'item2' ? 'font-weight:bold' : 'font-weight:normal'}" />
</a4j:outputPanel>
</a4j:outputPanel>
</h:form>
</rich:popupPanel>
<h:outputScript name="js/patch-popup-panel.js" />
{code}
was:
PopupPanel doesn't autosize correctly after move. Moving a PopupPanel with 'autosized' attribute enabled causes the width properties of its inner container div, content div, srcoller div, and shadow div to be hard-set such that a subsequent content change doesn't trigger the auto-resize of the PopupPanel any longer. The PopupPanel height is apparently unaffected.
Attached is a testcase to demonstrate the problem, see the attached zip file containing a minimal JSF application which reproduces the undesired behavior.
> PopupPanel autosize with togglePanel doesn't resize
> ---------------------------------------------------
>
> Key: RF-13616
> URL: https://issues.jboss.org/browse/RF-13616
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component
> Affects Versions: 4.2.3.Final, 4.3.6
> Reporter: abhishek vijra
> Labels: gss
> Fix For: 4.3.7
>
> Attachments: popupPanel.zip
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> PopupPanel doesn't autosize correctly after move. Moving a PopupPanel with 'autosized' attribute enabled causes the width properties of its inner container div, content div, srcoller div, and shadow div to be hard-set such that a subsequent content change doesn't trigger the auto-resize of the PopupPanel any longer. The PopupPanel height is apparently unaffected.
> Attached is a testcase to demonstrate the problem, see the attached zip file containing a minimal JSF application which reproduces the undesired behavior.
> {code}
> <ui:define name="body"
> onload="#{rich:component('popup')}.hide(); return false;">
> <h:outputStylesheet>
> .rf-tgp-itm {
> border: 1px solid #{richSkin.panelBorderColor};
> padding: 5px;
> }
>
> .tabDiv {
> margin: 0 5px 5px 0;
> border: 1px solid #{richSkin.panelBorderColor};
> background-color: #{richSkin.headerBackgroundColor};
> cursor: pointer;
> padding: 0 5px;
> float: left;
> }
> </h:outputStylesheet>
> <h:form>
> <h:commandButton value="Open the popup">
> <rich:componentControl target="popup" operation="show" />
> </h:commandButton>
> </h:form>
> <rich:popupPanel id="popup" modal="false" autosized="true"
> resizeable="false">
> <f:facet name="header">
> <h:outputText value="Demo PopupPanel" />
> </f:facet>
> <f:facet name="controls">
> <h:outputLink value="#"
> onclick="#{rich:component('popup')}.hide(); return false;">X</h:outputLink>
> </f:facet>
> <h:form>
> <rich:togglePanel id="panel1" activeItem="item1" render="tabs"
> itemChangeListener="#{panelMenuBean.processItemChange}">
> <rich:togglePanelItem name="item1">
> <h3>Panel Item 1</h3>
> <p>Steps to reproduce:</p>
> <p>1. Without moving the PopupPanel directly switch to Panel
> Item 2.</p>
> <p>3. Now move the PopupPanel around and then switch back to
> Panel Item 2.</p>
> </rich:togglePanelItem>
> <rich:togglePanelItem name="item2" style="width:777px">
> <h3>Panel Item 2</h3>
> <p>2. The PopupPanel is autosized, correctly adjusting to the
> size difference between its previous and its current content. Now
> switch back to Panel Item 1.</p>
> <p>4. As you notice, the PopupPanel isn't properly autosized
> anymore after first moving it but is now stuck to the smaller
> width of Panel Item 1, its previous content.</p>
> </rich:togglePanelItem>
> </rich:togglePanel>
> <a4j:outputPanel id="tabs" layout="block">
> <a4j:outputPanel layout="block" styleClass="tabDiv">
> <rich:toggleControl event="click" targetPanel="panel1"
> targetItem="item1" />
> <h:outputText value="Toggle Panel Item 1"
> style="#{rich:findComponent('panel1').activeItem == 'item1' ? 'font-weight:bold' : 'font-weight:normal'}" />
> </a4j:outputPanel>
> <a4j:outputPanel layout="block" styleClass="tabDiv">
> <rich:toggleControl event="click" targetPanel="panel1"
> targetItem="item2" />
> <h:outputText value="Toggle Panel Item 2"
> style="#{rich:findComponent('panel1').activeItem == 'item2' ? 'font-weight:bold' : 'font-weight:normal'}" />
> </a4j:outputPanel>
> </a4j:outputPanel>
> </h:form>
> </rich:popupPanel>
> <h:outputScript name="js/patch-popup-panel.js" />
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 12 months
[JBoss JIRA] (RF-13622) Undocumented feature - accordionItem header facets for specific states
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13622?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13622:
-------------------------------
Fix Version/s: 4.5-Tracking
Nice catch. These facets are documented in the component reference for the {{<rich:tab>}} component, but not for the {{<rich:accordionItem>}}:
http://docs.jboss.org/richfaces/latest_4_X/Component_Reference/en-US/html...
Looking through our vdldoc it seems we do not document any of our facets there. We should correct this. The vdldoc should contain _all_ aspects of component configuration, with the component reference used for looking up usage details of those configuration aspects.
> Undocumented feature - accordionItem header facets for specific states
> ----------------------------------------------------------------------
>
> Key: RF-13622
> URL: https://issues.jboss.org/browse/RF-13622
> Project: RichFaces
> Issue Type: Quality Risk
> Security Level: Public(Everyone can see)
> Components: doc
> Affects Versions: 4.3.3
> Reporter: David Rawlings
> Priority: Minor
> Fix For: 4.5-Tracking
>
>
> Having read the code I found that the richfaces accordion/accordionItem component supports the following:
> {code:xml}
> <rich:accordionItem>
> <f:facet name="headerActive">
> Some content for when item is active
> </f:facet>
> <f:facet name="headerInactive">
> Some content for when item is inactive
> </f:facet>
> <f:facet name="headerDisabled">
> Some content for when item is disabled
> </f:facet>
> </rich:accordionItem>
> {code}
> I can't find this feature documented anywhere. It would be useful to reference this in the vld docs for the 'header' attribute of the accordionItem tag.
> I found this feature useful to overcome issues I was having using rich:tooltip in an accordionItem header
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 12 months
[JBoss JIRA] (RF-13622) Undocumented feature - accordionItem header facets for specific states
by David Rawlings (JIRA)
[ https://issues.jboss.org/browse/RF-13622?page=com.atlassian.jira.plugin.s... ]
David Rawlings updated RF-13622:
--------------------------------
Priority: Minor (was: Major)
> Undocumented feature - accordionItem header facets for specific states
> ----------------------------------------------------------------------
>
> Key: RF-13622
> URL: https://issues.jboss.org/browse/RF-13622
> Project: RichFaces
> Issue Type: Quality Risk
> Security Level: Public(Everyone can see)
> Components: doc
> Affects Versions: 4.3.3
> Reporter: David Rawlings
> Priority: Minor
>
> Having read the code I found that the richfaces accordion/accordionItem component supports the following:
> {code:xml}
> <rich:accordionItem>
> <f:facet name="headerActive">
> Some content for when item is active
> </f:facet>
> <f:facet name="headerInactive">
> Some content for when item is inactive
> </f:facet>
> <f:facet name="headerDisabled">
> Some content for when item is disabled
> </f:facet>
> </rich:accordionItem>
> {code}
> I can't find this feature documented anywhere. It would be useful to reference this in the vld docs for the 'header' attribute of the accordionItem tag.
> I found this feature useful to overcome issues I was having using rich:tooltip in an accordionItem header
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 12 months
[JBoss JIRA] (RF-13622) Undocumented feature - accordionItem header facets for specific states
by David Rawlings (JIRA)
David Rawlings created RF-13622:
-----------------------------------
Summary: Undocumented feature - accordionItem header facets for specific states
Key: RF-13622
URL: https://issues.jboss.org/browse/RF-13622
Project: RichFaces
Issue Type: Quality Risk
Security Level: Public (Everyone can see)
Components: doc
Affects Versions: 4.3.3
Reporter: David Rawlings
Having read the code I found that the richfaces accordion/accordionItem component supports the following:
{code:xml}
<rich:accordionItem>
<f:facet name="headerActive">
Some content for when item is active
</f:facet>
<f:facet name="headerInactive">
Some content for when item is inactive
</f:facet>
<f:facet name="headerDisabled">
Some content for when item is disabled
</f:facet>
</rich:accordionItem>
{code}
I can't find this feature documented anywhere. It would be useful to reference this in the vld docs for the 'header' attribute of the accordionItem tag.
I found this feature useful to overcome issues I was having using rich:tooltip in an accordionItem header
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 12 months
[JBoss JIRA] (RF-13617) CDK - NPE getOutputFileName
by Lukáš Macko (JIRA)
[ https://issues.jboss.org/browse/RF-13617?page=com.atlassian.jira.plugin.s... ]
Lukáš Macko closed RF-13617.
----------------------------
Resolution: Done
> CDK - NPE getOutputFileName
> ---------------------------
>
> Key: RF-13617
> URL: https://issues.jboss.org/browse/RF-13617
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component
> Reporter: Lukáš Macko
> Priority: Blocker
>
> During backporting chart to 4.5.X I come across this exception. In RF5 CDK works ok.
> {code}
> {{[ERROR] Failed to execute goal org.richfaces.cdk:richfaces-cdk-maven-plugin:4.5.0.Alpha2:generate (cdk-generate-sources) on project richfaces-components-rich: Execution cdk-generate-sources of goal org.richfaces.cdk:richfaces-cdk-maven-plugin:4.5.0.Alpha2:generate failed: java.lang.reflect.InvocationTargetException: NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.richfaces.cdk:richfaces-cdk-maven-plugin:4.5.0.Alpha2:generate (cdk-generate-sources) on project richfaces-components-rich: Execution cdk-generate-sources of goal org.richfaces.cdk:richfaces-cdk-maven-plugin:4.5.0.Alpha2:generate failed: java.lang.reflect.InvocationTargetException
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> 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:320)
> 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:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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:414)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution cdk-generate-sources of goal org.richfaces.cdk:richfaces-cdk-maven-plugin:4.5.0.Alpha2:generate failed: java.lang.reflect.InvocationTargetException
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at com.sun.tools.javac.main.Main.compile(Main.java:469)
> at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:132)
> at org.richfaces.cdk.apt.AptBuilder.build(AptBuilder.java:47)
> at org.richfaces.cdk.Generator.execute(Generator.java:155)
> at org.richfaces.builder.mojo.GenerateMojo.execute(GenerateMojo.java:254)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.richfaces.cdk.apt.LibraryProxyInterceptor.invoke(LibraryProxyInterceptor.java:18)
> at org.richfaces.cdk.generate.java.taghandler.TagHandlerWriter.render(TagHandlerWriter.java:48)
> at org.richfaces.cdk.apt.DefaultLibraryGenerator.generate(DefaultLibraryGenerator.java:28)
> at org.richfaces.cdk.apt.CdkProcessorImpl.generate(CdkProcessorImpl.java:157)
> at org.richfaces.cdk.apt.CdkProcessorImpl.continueAfterJavaSourceProcessing(CdkProcessorImpl.java:133)
> at org.richfaces.cdk.apt.CdkProcessorImpl.process(CdkProcessorImpl.java:106)
> at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:793)
> at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$200(JavacProcessingEnvironment.java:97)
> at com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.runContributingProcs(JavacProcessingEnvironment.java:644)
> at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1027)
> at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1185)
> at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1108)
> at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:824)
> at com.sun.tools.javac.main.Main.compile(Main.java:439)
> ... 25 more
> Caused by: java.lang.NullPointerException
> at org.richfaces.cdk.generate.java.taghandler.TagHandlerClassGenerator.getOutputFileName(TagHandlerClassGenerator.java:87)
> at org.richfaces.cdk.generate.java.taghandler.TagHandlerClassGenerator.getOutput(TagHandlerClassGenerator.java:80)
> at org.richfaces.cdk.generate.java.taghandler.TagHandlerClassGenerator.process(TagHandlerClassGenerator.java:60)
> at org.richfaces.cdk.generate.java.taghandler.TagHandlerGeneratorVisitor.generateTagHandler(TagHandlerGeneratorVisitor.java:74)
> at org.richfaces.cdk.generate.java.taghandler.TagHandlerGeneratorVisitor.visitComponent(TagHandlerGeneratorVisitor.java:49)
> at org.richfaces.cdk.generate.java.taghandler.TagHandlerGeneratorVisitor.visitComponent(TagHandlerGeneratorVisitor.java:39)
> at org.richfaces.cdk.model.ComponentModel.accept(ComponentModel.java:45)
> at org.richfaces.cdk.model.ModelSet.accept(ModelSet.java:211)
> at org.richfaces.cdk.model.ModelSet.accept(ModelSet.java:206)
> at org.richfaces.cdk.model.ComponentLibrary.accept(ComponentLibrary.java:95)
> ... 43 more
> [ERROR]}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 12 months
[JBoss JIRA] (RF-13617) CDK - NPE getOutputFileName
by Lukáš Macko (JIRA)
[ https://issues.jboss.org/browse/RF-13617?page=com.atlassian.jira.plugin.s... ]
Lukáš Macko commented on RF-13617:
----------------------------------
Yes, I am able to proceed. Thank you Michal.
> CDK - NPE getOutputFileName
> ---------------------------
>
> Key: RF-13617
> URL: https://issues.jboss.org/browse/RF-13617
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component
> Reporter: Lukáš Macko
> Priority: Blocker
>
> During backporting chart to 4.5.X I come across this exception. In RF5 CDK works ok.
> {code}
> {{[ERROR] Failed to execute goal org.richfaces.cdk:richfaces-cdk-maven-plugin:4.5.0.Alpha2:generate (cdk-generate-sources) on project richfaces-components-rich: Execution cdk-generate-sources of goal org.richfaces.cdk:richfaces-cdk-maven-plugin:4.5.0.Alpha2:generate failed: java.lang.reflect.InvocationTargetException: NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.richfaces.cdk:richfaces-cdk-maven-plugin:4.5.0.Alpha2:generate (cdk-generate-sources) on project richfaces-components-rich: Execution cdk-generate-sources of goal org.richfaces.cdk:richfaces-cdk-maven-plugin:4.5.0.Alpha2:generate failed: java.lang.reflect.InvocationTargetException
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> 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:320)
> 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:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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:414)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution cdk-generate-sources of goal org.richfaces.cdk:richfaces-cdk-maven-plugin:4.5.0.Alpha2:generate failed: java.lang.reflect.InvocationTargetException
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at com.sun.tools.javac.main.Main.compile(Main.java:469)
> at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:132)
> at org.richfaces.cdk.apt.AptBuilder.build(AptBuilder.java:47)
> at org.richfaces.cdk.Generator.execute(Generator.java:155)
> at org.richfaces.builder.mojo.GenerateMojo.execute(GenerateMojo.java:254)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.richfaces.cdk.apt.LibraryProxyInterceptor.invoke(LibraryProxyInterceptor.java:18)
> at org.richfaces.cdk.generate.java.taghandler.TagHandlerWriter.render(TagHandlerWriter.java:48)
> at org.richfaces.cdk.apt.DefaultLibraryGenerator.generate(DefaultLibraryGenerator.java:28)
> at org.richfaces.cdk.apt.CdkProcessorImpl.generate(CdkProcessorImpl.java:157)
> at org.richfaces.cdk.apt.CdkProcessorImpl.continueAfterJavaSourceProcessing(CdkProcessorImpl.java:133)
> at org.richfaces.cdk.apt.CdkProcessorImpl.process(CdkProcessorImpl.java:106)
> at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:793)
> at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$200(JavacProcessingEnvironment.java:97)
> at com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.runContributingProcs(JavacProcessingEnvironment.java:644)
> at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1027)
> at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1185)
> at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1108)
> at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:824)
> at com.sun.tools.javac.main.Main.compile(Main.java:439)
> ... 25 more
> Caused by: java.lang.NullPointerException
> at org.richfaces.cdk.generate.java.taghandler.TagHandlerClassGenerator.getOutputFileName(TagHandlerClassGenerator.java:87)
> at org.richfaces.cdk.generate.java.taghandler.TagHandlerClassGenerator.getOutput(TagHandlerClassGenerator.java:80)
> at org.richfaces.cdk.generate.java.taghandler.TagHandlerClassGenerator.process(TagHandlerClassGenerator.java:60)
> at org.richfaces.cdk.generate.java.taghandler.TagHandlerGeneratorVisitor.generateTagHandler(TagHandlerGeneratorVisitor.java:74)
> at org.richfaces.cdk.generate.java.taghandler.TagHandlerGeneratorVisitor.visitComponent(TagHandlerGeneratorVisitor.java:49)
> at org.richfaces.cdk.generate.java.taghandler.TagHandlerGeneratorVisitor.visitComponent(TagHandlerGeneratorVisitor.java:39)
> at org.richfaces.cdk.model.ComponentModel.accept(ComponentModel.java:45)
> at org.richfaces.cdk.model.ModelSet.accept(ModelSet.java:211)
> at org.richfaces.cdk.model.ModelSet.accept(ModelSet.java:206)
> at org.richfaces.cdk.model.ComponentLibrary.accept(ComponentLibrary.java:95)
> ... 43 more
> [ERROR]}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 12 months