Error Starting Server
Is anyone else getting this error when trying to start the server ?? Or know how to resolve ?? Just started happening today java.net.BindException: Address already in use: JVM_Bind at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359) at java.net.ServerSocket.bind(ServerSocket.java:319) at java.net.ServerSocket.init(ServerSocket.java:185) at java.net.ServerSocket.init(ServerSocket.java:141) -- Thanks, Tim McConnell
Re: 1.2 TLD compatibility
Hi, I do not know the answer Adam's last question below concerning boolean versus java.language.Boolean, although I'm interested in the answer. Would someone else please advise ?? Thanks much. Tim McConnell Adam Winer wrote: On 4/30/07, *Tim McConnell* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Adam, thanks very much for reviewing my patches so promptly. Here are my comments to your comments: ADFFACES-475: - If the method name is immaterial at runtime then the only change for the companion MYFACES-1599 JIRA would be to update the return value which I've done with the patch attached to MYFACES-1599. If no one objects I think I should just close ADFFACES-475. ADFFACES-476: - I really like that solution. I shall provide you with another patch (assuming I can discern what the spec components are). I wouldn't hardcode in the plugin what a spec component is, etc. I'd make it a property of the plugin, so that in a pom you could have idExpressionsfalse/idExpressions ... and it would turn it off for that project. ADFFACES-477: - To be honest I was a bit hesitate to alter the current CAN_COERCE check since I was not fully certain of the implications. If there are none, then it seems the _CAN_COERCE map can be removed as well since that is the only place it is used. If that is the case I shall provide you with another patch. I'm not 100% sure of the implications either. :) I'll run some tests and make sure this doesn't break anything obvious. BTW, does it matter whether a deferred-value type is java.lang.Boolean or boolean? I figure they're identical in runtime behavior, since null will be coerced to Boolean.FALSE and false (I think). -- Adam
Re: 1.2 TLD compatibility
Adam Winer wrote: On 4/30/07, Adam Winer [EMAIL PROTECTED] wrote: On 4/30/07, Tim McConnell [EMAIL PROTECTED] wrote: Hi Adam, thanks very much for reviewing my patches so promptly. Here are my comments to your comments: ADFFACES-475: - If the method name is immaterial at runtime then the only change for the companion MYFACES-1599 JIRA would be to update the return value which I've done with the patch attached to MYFACES-1599. If no one objects I think I should just close ADFFACES-475. I've closed it. Thanks ADFFACES-476: - I really like that solution. I shall provide you with another patch (assuming I can discern what the spec components are). I wouldn't hardcode in the plugin what a spec component is, etc. I'd make it a property of the plugin, so that in a pom you could have idExpressionsfalse/idExpressions ... and it would turn it off for that project. I added disableIdExpressions which should do the trick for the spec components. Yes, it works beautifully ADFFACES-477: - To be honest I was a bit hesitate to alter the current CAN_COERCE check since I was not fully certain of the implications. If there are none, then it seems the _CAN_COERCE map can be removed as well since that is the only place it is used. If that is the case I shall provide you with another patch. I'm not 100% sure of the implications either. :) I'll run some tests and make sure this doesn't break anything obvious. I did some testing - one thing it immediately broke was the converter attribute when set to a String. The code generation was using valueExpression.getValue(null) when isLiteralText() was true, which will trigger a coercion (and failure). The fix is to use getExpressionString(). I've applied that fix to the MyFaces component generator (and the Trinidad as well, of course). But to be more conservative, I've only added Converter and UIComponent to the list of types that can appear in deferred-value/. Works as well I've also added a coerceStrings/ plugin configuration setting that can let you turn on java.lang.String coercion per project. -- Adam BTW, does it matter whether a deferred-value type is java.lang.Boolean or boolean? I figure they're identical in runtime behavior, since null will be coerced to Boolean.FALSE and false (I think). -- Adam Thanks Adam !! The patches attached to the companion MyFaces Jiras are now ready to be committed: MYFACES-1598 MYFACES-1599 MYFACES-1600 -- Thanks, Tim McConnell
[jira] Commented: (MYFACES-1600) JSF 1.2 TLD compliance: wrong deferred value for rendered and id should be false for the rtexpr value
[ https://issues.apache.org/jira/browse/MYFACES-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492689 ] Tim McConnell commented on MYFACES-1600: Opened a ADFFACES plugin companion defect (ADFFACES-476) for the ADFFACES patch, which can now be ignored. The MYFACES patch still needs to be applied though but I would prefer that the ADFFACES patch be reviewed and applied first to ensure I'm fixing this in the proper manner. Thanks. JSF 1.2 TLD compliance: wrong deferred value for rendered and id should be false for the rtexpr value - Key: MYFACES-1600 URL: https://issues.apache.org/jira/browse/MYFACES-1600 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Reporter: Bruno Aranda Assigned To: Tim McConnell Attachments: MYFACES-1600-ADFFACES.patch, MYFACES-1600.patch rendered - Expected deferred value type to be 'java.lang.Boolean' (now is 'boolean') id - Expected rtexpr value to be false (now is true) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1598) JSF 1.2 TLD compliance: attributes binding and converter with wrong deferred-type
[ https://issues.apache.org/jira/browse/MYFACES-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492693 ] Tim McConnell commented on MYFACES-1598: I opened a ADFFACES plugin companion defect (ADFFACES-477) for the ADFFACES patch, which can now be ignored. The MYFACES patch still needs to be applied though but I would prefer that the ADFFACES patch be reviewed and applied first to ensure I'm fixing this in the proper manner. Thanks. JSF 1.2 TLD compliance: attributes binding and converter with wrong deferred-type - Key: MYFACES-1598 URL: https://issues.apache.org/jira/browse/MYFACES-1598 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Reporter: Bruno Aranda Assigned To: Tim McConnell Attachments: MYFACES-1598-ADFFACES.patch, MYFACES-1598.patch For binding the deferred-type must be 'javax.faces.component.UIComponent' For converter the deferred-type must be 'javax.faces.convert.Converter' Now the deferred-type tags in the tld for these attributes are empty (hence expeting java.jang.Object) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1599) JSF 1.2 TLD compliance: attribute action with wrong deferred-method signature
[ https://issues.apache.org/jira/browse/MYFACES-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492694 ] Tim McConnell commented on MYFACES-1599: I opened an ADFFACES plugin companion defect (ADFFACES-475) for the ADFFACES patch, which can now be ignored. The MYFACES patch still needs to be applied though but I would prefer that the ADFFACES patch be reviewed and applied first to ensure I'm fixing this in the proper manner. Thanks. JSF 1.2 TLD compliance: attribute action with wrong deferred-method signature Key: MYFACES-1599 URL: https://issues.apache.org/jira/browse/MYFACES-1599 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Reporter: Bruno Aranda Assigned To: Tim McConnell Attachments: MYFACES-1599-ADFFACES.patch, MYFACES-1599.patch The expected deferred-method for the attribute action is 'java.lang.Object action()', Now we have 'java.lang.String myMethod()' - wrong -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 1.2 TLD compatibility
Hi Adam, thanks very much for reviewing my patches so promptly. Here are my comments to your comments: ADFFACES-475: - If the method name is immaterial at runtime then the only change for the companion MYFACES-1599 JIRA would be to update the return value which I've done with the patch attached to MYFACES-1599. If no one objects I think I should just close ADFFACES-475. ADFFACES-476: - I really like that solution. I shall provide you with another patch (assuming I can discern what the spec components are). ADFFACES-477: - To be honest I was a bit hesitate to alter the current CAN_COERCE check since I was not fully certain of the implications. If there are none, then it seems the _CAN_COERCE map can be removed as well since that is the only place it is used. If that is the case I shall provide you with another patch. Thanks, Tim McConnell Adam Winer wrote: I'm checking out the following three issues, and have comments on the patches for each. https://issues.apache.org/jira/browse/ADFFACES-475: - Changes the deferred-method method name from myMethod() to action(). I don't get it. The method name in the TLD has zero runtime meaning. The spec should not require any particular name, and it'd be a spec bug if it does (or, at least, the spec should clarify). If we're going to change anything, I'd rather change the method name from generically being myMethod() to always being the TLD attribute name (e.g., action(), beforePhase(), etc.). But, mostly I'm inclined to push back on the spec. https://issues.apache.org/jira/browse/ADFFACES-476: - Changes rtexprvalue on id from true to false Supporting rtexprvalue on id is useful for component libs. I think this should be a configurable option on the plugin (by default, on) that we can turn off for the spec components but keep on for Trinidad + Tomahawk. https://issues.apache.org/jira/browse/ADFFACES-477 - Changes the deferred-value type on converter and binding from java.lang.Object to the appropriate type I'm OK with this one, though I don't see any RT benefits. There's some small tooling benefit to the change. I think the simplest change to make is removing the current CAN_COERCE check in the code, instead of hardcoding binding and converter as special attrs. -- Adam
[jira] Updated: (MYFACES-1599) JSF 1.2 TLD compliance: attribute action with wrong deferred-method signature
[ https://issues.apache.org/jira/browse/MYFACES-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated MYFACES-1599: --- Status: Patch Available (was: Open) JSF 1.2 TLD compliance: attribute action with wrong deferred-method signature Key: MYFACES-1599 URL: https://issues.apache.org/jira/browse/MYFACES-1599 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Reporter: Bruno Aranda Assigned To: Tim McConnell The expected deferred-method for the attribute action is 'java.lang.Object action()', Now we have 'java.lang.String myMethod()' - wrong -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1600) JSF 1.2 TLD compliance: wrong deferred value for rendered and id should be false for the rtexpr value
[ https://issues.apache.org/jira/browse/MYFACES-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated MYFACES-1600: --- Status: Patch Available (was: Open) JSF 1.2 TLD compliance: wrong deferred value for rendered and id should be false for the rtexpr value - Key: MYFACES-1600 URL: https://issues.apache.org/jira/browse/MYFACES-1600 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Reporter: Bruno Aranda Assigned To: Tim McConnell rendered - Expected deferred value type to be 'java.lang.Boolean' (now is 'boolean') id - Expected rtexpr value to be false (now is true) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1598) JSF 1.2 TLD compliance: attributes binding and converter with wrong deferred-type
[ https://issues.apache.org/jira/browse/MYFACES-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated MYFACES-1598: --- Status: Patch Available (was: Open) JSF 1.2 TLD compliance: attributes binding and converter with wrong deferred-type - Key: MYFACES-1598 URL: https://issues.apache.org/jira/browse/MYFACES-1598 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Reporter: Bruno Aranda Assigned To: Tim McConnell For binding the deferred-type must be 'javax.faces.component.UIComponent' For converter the deferred-type must be 'javax.faces.convert.Converter' Now the deferred-type tags in the tld for these attributes are empty (hence expeting java.jang.Object) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ADFFACES-467 Jira and MyFaces TLD Compliance Jira(s)
Hi Bruno, that is wonderful news !! Obviously I was not using the correct
branch. I shall now do the same--thanks very much for you assistance.
Thanks,
Tim McConnell
Bruno Aranda wrote:
Hi Tim, I have just done a fresh checkout from the latest branch:
svn co
http://svn.apache.org/repos/asf/incubator/adffaces/branches/faces-1_2-070427/
trinidad1_2-070427
cd trinidad1_2-070427
cd plugins
cd maven-faces-plugin
mvn install
And then I have changed the POMs in core/build and core/impl to use
the locally installed version incubator-1.2-07-apr-SNAPSHOT and the
build goes ok, without errors.
I have also checked
AbstractComponentGenerator.convertStringToBoxedLiteral(AbstractComponentGenerator.java:433)
and the exception is not thrown in that line anymore, so I guess you
are not using the latest branch?
Cheers and thanks for the help in 1.2,
Bruno
On 27/04/07, Tim McConnell [EMAIL PROTECTED] wrote:
Hi MyFaces community. I'm trying to resolve a problem in MyFaces
documented in
the ADFFACES-467 Jira. According to a comment on the Jira the patch I
attached
was for a obsolete branch. However, when I try to use the
ADFFACES/faces-1_2
branch I get build errors below when trying to build MyFaces 1.2. The
obsolete
branch (ADFFACES/faces-1_2-061113) does not cause this error when
building
MyFaces 1.2. So, just have a couple questions:
1. Does anyone know what is causing the error below ?? And what I
need to
do to resolve it ??
2. How does one know which ADFFACES branch the MyFaces community
should be
using for the maven-faces-plugin ??
If I can just figure out where to put the patch I can quickly resolve
a number
of Jiras related to TLD issues. Thanks very much for any assistance !!
Tim McConnell
[INFO] Building API
[INFO]task-segment: [install]
[INFO]
[INFO] [faces:generate-components {execution: default}]
log4j:WARN No appenders could be found for logger
(org.apache.commons.digester.Digester.sax).
log4j:WARN Please initialize the log4j system properly.
[WARNING] Missing component-family for
javax.faces.component.UIColumn,
generation of this Component is skipped
[WARNING] Missing component-family for
javax.faces.component.UIComponent,
generation of this Component is skipped
[WARNING] Missing component-family for
javax.faces.component.UIComponentBase, generation of this Component
is skipped
[WARNING] Missing component-family for javax.faces.component.UIForm,
generation of this Component is skipped
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.IllegalStateException
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.component.AbstractComponentGenerator.convertStringToBoxedLiteral(AbstractComponentGenerator.java:433)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.component.TrinidadComponentGenerator.writePropertyConstants(TrinidadComponentGenerator.java:127)
at
org.apache.myfaces.trinidadbuild.plugin.faces.GenerateComponentsMojo._generateComponent(GenerateComponentsMojo.java:199)
at
org.apache.myfaces.trinidadbuild.plugin.faces.GenerateComponentsMojo._generateComponents(GenerateComponentsMojo.java:99)
at
org.apache.myfaces.trinidadbuild.plugin.faces.GenerateComponentsMojo.execute(GenerateComponentsMojo.java:54)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
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:585
ADFFACES-467 Jira and MyFaces TLD Compliance Jira(s)
Hi MyFaces community. I'm trying to resolve a problem in MyFaces documented in
the ADFFACES-467 Jira. According to a comment on the Jira the patch I attached
was for a obsolete branch. However, when I try to use the ADFFACES/faces-1_2
branch I get build errors below when trying to build MyFaces 1.2. The obsolete
branch (ADFFACES/faces-1_2-061113) does not cause this error when building
MyFaces 1.2. So, just have a couple questions:
1. Does anyone know what is causing the error below ?? And what I need to
do to resolve it ??
2. How does one know which ADFFACES branch the MyFaces community should be
using for the maven-faces-plugin ??
If I can just figure out where to put the patch I can quickly resolve a number
of Jiras related to TLD issues. Thanks very much for any assistance !! Tim McConnell
[INFO] Building API
[INFO]task-segment: [install]
[INFO]
[INFO] [faces:generate-components {execution: default}]
log4j:WARN No appenders could be found for logger
(org.apache.commons.digester.Digester.sax).
log4j:WARN Please initialize the log4j system properly.
[WARNING] Missing component-family for javax.faces.component.UIColumn,
generation of this Component is skipped
[WARNING] Missing component-family for javax.faces.component.UIComponent,
generation of this Component is skipped
[WARNING] Missing component-family for
javax.faces.component.UIComponentBase, generation of this Component is skipped
[WARNING] Missing component-family for javax.faces.component.UIForm,
generation of this Component is skipped
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.IllegalStateException
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.component.AbstractComponentGenerator.convertStringToBoxedLiteral(AbstractComponentGenerator.java:433)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.component.TrinidadComponentGenerator.writePropertyConstants(TrinidadComponentGenerator.java:127)
at
org.apache.myfaces.trinidadbuild.plugin.faces.GenerateComponentsMojo._generateComponent(GenerateComponentsMojo.java:199)
at
org.apache.myfaces.trinidadbuild.plugin.faces.GenerateComponentsMojo._generateComponents(GenerateComponentsMojo.java:99)
at
org.apache.myfaces.trinidadbuild.plugin.faces.GenerateComponentsMojo.execute(GenerateComponentsMojo.java:54)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
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:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
--
Thanks,
Tim McConnell
Re: [SVN] - Help ? svn mv
Hi Matthias, do you plan to move everything in adffaces to MyFaces ?? I only ask since there appears to be a lot of code in adffaces that may be obsolete, at least based on some of the folder names (e.g., faces-1_2-old, trunk_backup). Thanks, Tim McConnell Matthias Wessendorf wrote: Hi, it sounds like a really straight forward task, but.. are there any (known) issue w/ a svn move ? I'd like to move the Trinidad folder (named adffaces) from Incubator to MyFaces (with the name trinidad). Thanks, Matthias
JIRA Permissions
Hi, I'm helping Paul McMahan work through some of the JSR-252 JIRAs. Could someone update the permissions on my JIRA profile (mcconne) so that I can assign myself existing issues, and to open new issues, for the MyFaces project ?? -- Thanks, Tim McConnell
Re: JIRA Permissions
Hi Mike/Dennis, Thanks for the info... Tim McConnell Dennis Byrne wrote: We've had this discussion in the past. I think the outcome was to pair up w/ a committer who would assign the bug to themselves on your behalf. If this doesn't work, perhaps a I'm working on this comment will do. Thanks for your interest Tim. Dennis Byrne On 4/25/07, *Mike Kienenberger* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Tim, You should already be able to open new issues. There's no point in giving you the ability to assign yourself to an issue until you have commit access.For now, just attach patches and mark the issue accordingly. On 4/25/07, Tim McConnell [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, I'm helping Paul McMahan work through some of the JSR-252 JIRAs. Could someone update the permissions on my JIRA profile (mcconne) so that I can assign myself existing issues, and to open new issues, for the MyFaces project ?? -- Thanks, Tim McConnell -- Dennis Byrne
Re: JIRA Permissions
Hi Manfred, yes I can do that now--thanks much !! Tim McConnell Manfred Geiler wrote: Mike/Dennis, There is a special group for guys like Tim: myfaces-contributors Tim, I just added you to this group. You should now be able to assign and resolve issues. Thanks for your help! --Manfred On 4/25/07, Tim McConnell [EMAIL PROTECTED] wrote: Hi Mike/Dennis, Thanks for the info... Tim McConnell Dennis Byrne wrote: We've had this discussion in the past. I think the outcome was to pair up w/ a committer who would assign the bug to themselves on your behalf. If this doesn't work, perhaps a I'm working on this comment will do. Thanks for your interest Tim. Dennis Byrne On 4/25/07, *Mike Kienenberger* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Tim, You should already be able to open new issues. There's no point in giving you the ability to assign yourself to an issue until you have commit access.For now, just attach patches and mark the issue accordingly. On 4/25/07, Tim McConnell [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, I'm helping Paul McMahan work through some of the JSR-252 JIRAs. Could someone update the permissions on my JIRA profile (mcconne) so that I can assign myself existing issues, and to open new issues, for the MyFaces project ?? -- Thanks, Tim McConnell -- Dennis Byrne
Re: JSF 1.2 status update
Hi Martin, I am looking at MYFACES-1587 below and the corresponding Geronimo JIRA (GERONIMO-3038) Thanks, Tim McConnell Martin Haimberger wrote: Hi *, Nice greatings from Christoph Ebner and me. A lot of issues have been resolved since our last status update, but there are also some new issues. Here is the updated list of last time: MYFACES-1563 - Martin will ovetake this from Christoph. MYFACES-1255 - resolved MYFACES-1264 - Christoph will do that. MYFACES-1253 - resolved MYFACES-1204 - resolved MYFACES-1236 - This issues is open. Needs to be done if the JSF 1.2 implementation is nearly done. Can somebody overtake this please? MYFACES-1251 - resolved. MYFACES-1217 - Implemented christoph will recheck this. MYFACES-1200 - This issues is open. Needs to be done if the JSF 1.2 implementation is nearly done. Can somebody overtake this please? MYFACES-1434 - Just two tags left, convertDateTimeTag patch available, FacetTag is in progress. MYFACES-1444 - resolved MYFACES-1109 - Regarding the comment from Mathias Broekelmann, this is not compatible with the JSF 1.2 specification. Could be done for t:dataTable MYFACES-1548 - resolved MYFACES-1564 - could not reconstruct the bug. Can somebody take a look at it to affirm? MYFACES-1220 - closed MYFACES-1221 - resolved MYFACES-1230 - resolved MYFACES-1582 - patch available (xsd attached) MYFACES-1584 - resolved MYFACES-1223 - low priority Here are the new, unassigned issues: MYFACES-1587 - Can somebody take a look at it? MYFACES-1594 - Christoph will do that. We hope this helps. Regards, Christoph Ebner and Martin Haimberger On 4/20/07, Martin Haimberger [EMAIL PROTECTED] wrote: Hy, a short update from my side: MYFACES-1204 - patch available. MYFACES-1434 - was allready done. MYFACES-1221 - tests available. Regards, Martin On 4/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hey Martin, any updates here ? (any patches that are still sitting in jira ?) -M On 4/6/07, Martin Haimberger [EMAIL PROTECTED] wrote: Hi *, Nice greatings from Christoph Ebner and me. Now a short overview of the JSF 1.2 implementation status. We looked over the unassigned issues: MYFACES-1563 - Christoph will do that. MYFACES-1255 - Crosschecked with RI - Only javadoc MYFACES-1264 - Christoph will do that. MYFACES-1253 - Crosschecked with RI - Only javadoc and specification MYFACES-1204 - Martin (me) will check this. MYFACES-1236 - This issues is open. MYFACES-1251 - This issues is open. Needs to be done if the JSF 1.2 implementation is nearly done. MYFACES-1217 - Implemented christoph will recheck this. MYFACES-1200 - This issues is open. Needs to be done if the JSF 1.2 implementation is nearly done. MYFACES-1434 - Martin (me) will do Add element deferred-value/method for elements in the taglibs MYFACES-1444 - patch available MYFACES-1109 - Regarding the comment from Mathias Broekelmann, this is not compatible with the JSF 1.2 specification. Could be done for t:dataTable MYFACES-1548 - patch available MYFACES-1564 - Christoph Ebner will do that. MYFACES-1220 - This issue is open. MYFACES-1221 - Martin (me) will test this with an own renderkit. MYFACES-1230 - Specification Request, someone should recheck this. MYFACES-1582 - patch available MYFACES-1584 - patch available MYFACES-1223 - low priority I hope this helps. Regards, Christoph Ebner and Martin Haimberger -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Updated: (MYFACES-1587) generated h.tld doesn't conform to schema
[ https://issues.apache.org/jira/browse/MYFACES-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated MYFACES-1587: --- Status: Patch Available (was: Open) generated h.tld doesn't conform to schema - Key: MYFACES-1587 URL: https://issues.apache.org/jira/browse/MYFACES-1587 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan The TLD at target/classes/META-INF/h.tld that is generated ( IIUC ) by the maven plugin does not conform to the schema it references http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd. See GERONIMO-3038 for an exhaustive list of parse errors. The file at core/impl/src/main/tld/myfaces_html.tld appears to be a more accurate version of this TLD but does not end up in the myfaces-impl jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: current12 build errors
Wonderful. Thanks, Tim McConnell Mathias Brökelmann wrote: Hi Tim, I tried building current12 and got the same error. I found out that changing the version for the two el dependencies from 1.2 to 1.0 for the test-webapp module fixed that problem. I changed that in svn. 2007/1/31, Tim McConnell [EMAIL PROTECTED]: Hi, I'm still unable to build the MyFaces 1.2 code. Originally I was getting errors in the HtmlMessagesRendererTest. Since then I've disabled all the tests but am getting failures to resolve artifacts (see below). Does anyone know how to resolve these ?? [INFO] Failed to resolve artifact. Missing: -- 1) com.sun.el:el-ri:jar:1.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.sun.el -DartifactId=el-ri \ -Dversion=1.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.myfaces:test-webapp:war:1.2.0-SNAPSHOT 2) com.sun.el:el-ri:jar:1.2 2) javax.el:el-api:jar:1.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=javax.el -DartifactId=el-api \ -Dversion=1.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.myfaces:test-webapp:war:1.2.0-SNAPSHOT 2) javax.el:el-api:jar:1.2 -- 2 required artifacts are missing. for artifact: org.apache.myfaces:test-webapp:war:1.2.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://maven1.glassfishwiki.org), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), java-net (https://maven-repository.dev.java.net/nonav/repository/), maven2-repository.dev.java.net (https://maven2-repository.dev.java.net/nonav/repository) -- Thanks, Tim McConnell
Re: Geronimo 2.0
Hi Martin, thanks much for the information. Do you have any idea when official snapshots for 1.2 will be published to a maven repo ?? Or is that something I should ask Bruno ?? Thanks. Martin Marinschek wrote: Hi Tim, -- this definitely seems like a reasonable target, what w've heard from Bruno on this list, who's working on it mostly currently. -- the plans of the community have been to have it much earlier, but well, Open Source is not always on time -- My personal view: yes, definitely -- No glaring gaps - it's mostly done, what is missing is minor regards, Martin On 2/6/07, Tim McConnell [EMAIL PROTECTED] wrote: Hi again, the Geronimo project is interested in having a 2.0 release (that is JEE 5 compliant) by the end of April 2007, with the hope/intention of including the MyFaces JSF 1.2 implementation. From a Geronimo perspective that would mean that we would require a released version of MyFaces 1.2 at the end of March 2007. Based on my interpretation of the current state of MyFaces 1.2 that seems like reasonable target, but I don't want to assume on behalf of others (and incorrectly). So I should wish to properly verify with the you, the MyFaces community: -- Does this seem like a reasonable target for MyFaces 1.2 ?? -- Does this hopefully track with what was already planned for MyFaces 1.2 ?? -- Would inclusion of MyFaces 1.2 into the next Geronimo release be viewed positively by the MyFaces project ?? -- Since it seems that the MyFaces 1.2 code currently seems to be fairly functional (with some known and obviously unknown caveats), are there any glaring gaps that are not obvious to me ?? Or any glaring gaps that the Geronimo project should know about and/or anticipate ?? Again, thanks for your assistance -- Thanks, Tim McConnell -- Thanks, Tim McConnell
Geronimo 2.0
Hi again, the Geronimo project is interested in having a 2.0 release (that is JEE 5 compliant) by the end of April 2007, with the hope/intention of including the MyFaces JSF 1.2 implementation. From a Geronimo perspective that would mean that we would require a released version of MyFaces 1.2 at the end of March 2007. Based on my interpretation of the current state of MyFaces 1.2 that seems like reasonable target, but I don't want to assume on behalf of others (and incorrectly). So I should wish to properly verify with the you, the MyFaces community: -- Does this seem like a reasonable target for MyFaces 1.2 ?? -- Does this hopefully track with what was already planned for MyFaces 1.2 ?? -- Would inclusion of MyFaces 1.2 into the next Geronimo release be viewed positively by the MyFaces project ?? -- Since it seems that the MyFaces 1.2 code currently seems to be fairly functional (with some known and obviously unknown caveats), are there any glaring gaps that are not obvious to me ?? Or any glaring gaps that the Geronimo project should know about and/or anticipate ?? Again, thanks for your assistance -- Thanks, Tim McConnell
Re: Myfaces 1.2 Status for (Geronimo usage)
Hi Bruno, thanks very much for the update Bruno Aranda wrote: Hi, I am experiencing a peak of work in my day job and I haven't been able to do anything for 1.2 in the last week. Basically, I was trying to run the test-webapp application in the myfaces 1.2 branch. Basically now there seems to be some issue with the tld, as the startup listener is not automatically started when started the app. If someone can fix that, I have everything prepared to run the TCK so we can spot other issues, Cheers, Bruno On 31/01/07, *Werner Punz* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Matthias Wessendorf schrieb: the jsf 1.2 stuff is in an early stage and not yet ready to use. I was able to deploy a JSF 1.2 app with it, but didn't get any feedback on the browser or exceptions. any helping hand is welcome ;-) -- Thanks, Tim McConnell
current12 build errors
Hi, I'm still unable to build the MyFaces 1.2 code. Originally I was getting errors in the HtmlMessagesRendererTest. Since then I've disabled all the tests but am getting failures to resolve artifacts (see below). Does anyone know how to resolve these ?? [INFO] Failed to resolve artifact. Missing: -- 1) com.sun.el:el-ri:jar:1.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.sun.el -DartifactId=el-ri \ -Dversion=1.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.myfaces:test-webapp:war:1.2.0-SNAPSHOT 2) com.sun.el:el-ri:jar:1.2 2) javax.el:el-api:jar:1.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=javax.el -DartifactId=el-api \ -Dversion=1.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.myfaces:test-webapp:war:1.2.0-SNAPSHOT 2) javax.el:el-api:jar:1.2 -- 2 required artifacts are missing. for artifact: org.apache.myfaces:test-webapp:war:1.2.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://maven1.glassfishwiki.org), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), java-net (https://maven-repository.dev.java.net/nonav/repository/), maven2-repository.dev.java.net (https://maven2-repository.dev.java.net/nonav/repository) -- Thanks, Tim McConnell
Myfaces 1.2 Status for (Geronimo usage)
Hi, I'm still am not getting a good sense for the current functional status of Myfaces 1.2. The Geronimo community is setting up the TCK for JEE5 compliance testing and we still haven't been able to use any JSF 1.2 functionality. Is there anyone who might be able to shed some light on the current status and possibly a rough time frame for when we might have a fully functional JSR-252 implementation. Please advise. Thanks much -- Tim McConnell
Re: JSR 252 and Geronimo Milestone 2
Hi Bruno, any thoughts on whether a MyFaces 1.2 snapshots can be available for Geronimo's usage anytime this week ?? I also notice that my local build of MyFaces 1.2 is failing--is that to be expected ?? Thanks much Bruno Aranda wrote: Hi Tim, At this very moment I am working in the ViewHandler implementation, which is the class that will allow to render the html created by the component renderers into the page. Once this is done, hopefully this week, probably we will be near of a functional implementation of jsf 1.2 (although it will be one with *some* bugs I guess). So, if there are no major drawbacks, myfaces 1.2 could be functional for the next milestone of Geronimo, but we should wait to the beginning of next week to really know :) Cheers! Bruno On 08/01/07, *Tim McConnell* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Geronimo has another JEE5 Milestone (2) release coming at the end of January. Has there been any recent progress on the JSR-252 implementation of MyFaces 1.2 such that we can include a functional snapshot within the next couple of weeks. Please advise. -- Thanks, Tim McConnell -- Thanks, Tim McConnell
Re: JSR 252 and Geronimo Milestone 2
Hi Matthias, yes I'm getting this failure belowI'll comment out as well to see how much farther I get. Thanks much --- T E S T S --- Running org.apache.myfaces.application.NavigationHandlerImplTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.25 sec Running org.apache.myfaces.renderkit.html.HtmlMessagesRendererTest Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.171 sec FAILURE! Matthias Wessendorf wrote: Tim, is it the htmlMessages test ? I commented it out for my quick runs. I was able to deploy a jsf 1.2 app with that snapshot but runing is not really going now -M On 1/18/07, Tim McConnell [EMAIL PROTECTED] wrote: Hi Bruno, any thoughts on whether a MyFaces 1.2 snapshots can be available for Geronimo's usage anytime this week ?? I also notice that my local build of MyFaces 1.2 is failing--is that to be expected ?? Thanks much Bruno Aranda wrote: Hi Tim, At this very moment I am working in the ViewHandler implementation, which is the class that will allow to render the html created by the component renderers into the page. Once this is done, hopefully this week, probably we will be near of a functional implementation of jsf 1.2 (although it will be one with *some* bugs I guess). So, if there are no major drawbacks, myfaces 1.2 could be functional for the next milestone of Geronimo, but we should wait to the beginning of next week to really know :) Cheers! Bruno On 08/01/07, *Tim McConnell* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Geronimo has another JEE5 Milestone (2) release coming at the end of January. Has there been any recent progress on the JSR-252 implementation of MyFaces 1.2 such that we can include a functional snapshot within the next couple of weeks. Please advise. -- Thanks, Tim McConnell -- Thanks, Tim McConnell -- Thanks, Tim McConnell
JSR 252 and Geronimo Milestone 2
Hi, Geronimo has another JEE5 Milestone (2) release coming at the end of January. Has there been any recent progress on the JSR-252 implementation of MyFaces 1.2 such that we can include a functional snapshot within the next couple of weeks. Please advise. -- Thanks, Tim McConnell
Re: MyFaces 1.2
Hi Bruno and Matthias, thanks much for the information. Matthias Wessendorf wrote: On 12/8/06, Bruno Aranda [EMAIL PROTECTED] wrote: Hi Tim, There is currently heavy development on those two artifacts as we are moving towards jsf 1.2. In its current state, though, they are still not working ok (which means thay they are currently broken, a part from not being fully compliant yet), although I guess it is a matter of adjusting a few issues to have them working and somewhat closer to the 1.2 spec I personally don't have the permissions to publish them in the repo, although you have my mvn deploy ? +1 same here +1 in that, in case you want to include the broken jars now. They are supposed to be working anytime soon (hopefully for your next milestone!) Cheers, Bruno On 07/12/06, Tim McConnell [EMAIL PROTECTED] wrote: HI again Wendy, To be politically correct I would like to formally ask permission from the MyFaces community to integrate these twp MyFaces SNAPSHOT's into the upcoming Geronimo Milestone Release (M1 set for 12-22-2006). This Geronimo milestone is to be available only for 30 days and will subsequently be followed by a more official Milestone 2 early next year. 1 -- myfaces-api-1.2.0-SNAPSHOT.jar 2 -- myfaces-impl-1.2.0-SNAPSHOT.jar Likewise, since I've not seen these two MyFaces 1.2 SNAPSHOT's published in a maven repository (and I need them tomorrow for inclusion), I would like to integrate them from my own local build if that is okay. Does anyone have a problem with either of these two requests ?? Sorry for the late notice--I just found out that I needed to get permission on behalf of Geronimo. Thanks very much Tim McConnell Wendy Smoak wrote: On 12/6/06, Tim McConnell [EMAIL PROTECTED] wrote: Thanks for the information Wendy. BTW, have another question. I see a number of SNAPSHOT jar files created when I build MyFaces 1.2. Which ones should we integrated into Geronimo ?? I'm guessing these but would like some verification if possible. -- myfaces-api-1.2.0-SNAPSHOT -- myfaces-impl-1.2.0-SNAPSHOT -- myfaces-shared-core-3.0.0-SNAPSHOT -- myfaces-shared-impl-3.0.0-SNAPSHOT -- myfaces-shared-tomahawk-3.0.0-SNAPSHOT You should just need the api and impl jars. Shared gets repackaged at build time, and Tomahawk is a custom component library.
Re: MyFaces 1.2
Hi Bruno, Even with the caveat that they may be broken at this point as a good first step I will be still be able to get these jars integrated into the Geronimo build, and hopefully will be able to deploy Web Applications that include JSF. Which brings up my next question. Are there sample JSF 1.2 applications I can test with ?? I see some Tobago examples on the Apache MyFaces wiki but I assume those are only for 1.1. Thanks much Tim McConnell Bruno Aranda wrote: Hi Tim, There is currently heavy development on those two artifacts as we are moving towards jsf 1.2. In its current state, though, they are still not working ok (which means thay they are currently broken, a part from not being fully compliant yet), although I guess it is a matter of adjusting a few issues to have them working and somewhat closer to the 1.2 spec I personally don't have the permissions to publish them in the repo, although you have my +1 in that, in case you want to include the broken jars now. They are supposed to be working anytime soon (hopefully for your next milestone!) Cheers, Bruno On 07/12/06, Tim McConnell [EMAIL PROTECTED] wrote: HI again Wendy, To be politically correct I would like to formally ask permission from the MyFaces community to integrate these twp MyFaces SNAPSHOT's into the upcoming Geronimo Milestone Release (M1 set for 12-22-2006). This Geronimo milestone is to be available only for 30 days and will subsequently be followed by a more official Milestone 2 early next year. 1 -- myfaces-api-1.2.0-SNAPSHOT.jar 2 -- myfaces-impl-1.2.0-SNAPSHOT.jar Likewise, since I've not seen these two MyFaces 1.2 SNAPSHOT's published in a maven repository (and I need them tomorrow for inclusion), I would like to integrate them from my own local build if that is okay. Does anyone have a problem with either of these two requests ?? Sorry for the late notice--I just found out that I needed to get permission on behalf of Geronimo. Thanks very much Tim McConnell Wendy Smoak wrote: On 12/6/06, Tim McConnell [EMAIL PROTECTED] wrote: Thanks for the information Wendy. BTW, have another question. I see a number of SNAPSHOT jar files created when I build MyFaces 1.2. Which ones should we integrated into Geronimo ?? I'm guessing these but would like some verification if possible. -- myfaces-api-1.2.0-SNAPSHOT -- myfaces-impl-1.2.0-SNAPSHOT -- myfaces-shared-core-3.0.0-SNAPSHOT -- myfaces-shared-impl-3.0.0-SNAPSHOT -- myfaces-shared-tomahawk-3.0.0-SNAPSHOT You should just need the api and impl jars. Shared gets repackaged at build time, and Tomahawk is a custom component library.
Re: MyFaces 1.2
HI again Wendy, To be politically correct I would like to formally ask permission from the MyFaces community to integrate these twp MyFaces SNAPSHOT's into the upcoming Geronimo Milestone Release (M1 set for 12-22-2006). This Geronimo milestone is to be available only for 30 days and will subsequently be followed by a more official Milestone 2 early next year. 1 -- myfaces-api-1.2.0-SNAPSHOT.jar 2 -- myfaces-impl-1.2.0-SNAPSHOT.jar Likewise, since I've not seen these two MyFaces 1.2 SNAPSHOT's published in a maven repository (and I need them tomorrow for inclusion), I would like to integrate them from my own local build if that is okay. Does anyone have a problem with either of these two requests ?? Sorry for the late notice--I just found out that I needed to get permission on behalf of Geronimo. Thanks very much Tim McConnell Wendy Smoak wrote: On 12/6/06, Tim McConnell [EMAIL PROTECTED] wrote: Thanks for the information Wendy. BTW, have another question. I see a number of SNAPSHOT jar files created when I build MyFaces 1.2. Which ones should we integrated into Geronimo ?? I'm guessing these but would like some verification if possible. -- myfaces-api-1.2.0-SNAPSHOT -- myfaces-impl-1.2.0-SNAPSHOT -- myfaces-shared-core-3.0.0-SNAPSHOT -- myfaces-shared-impl-3.0.0-SNAPSHOT -- myfaces-shared-tomahawk-3.0.0-SNAPSHOT You should just need the api and impl jars. Shared gets repackaged at build time, and Tomahawk is a custom component library.
MyFaces 1.2
Hi, I've notice lately that there is a lot of activity around the MyFaces 1.2 release. I'm wondering if there is there a MyFaces 1.2 SNAPSHOT available in a maven repro that can be used for an upcoming Geronimo 2.0 Milestone ?? If so, where can I find it ?? If not, would it be too much to ask for one to be created so that we can incorporate it into our milestone build. Obviously, it doesn't have to be fully functional yet since we understand it's not fully implemented yet, but we're basically just trying to start integrating all of our dependencies for next year's 2.0 release. Thanks for any assistance Tim McConnell
Re: MyFaces 1.2
Thanks for the information Wendy. BTW, have another question. I see a number of SNAPSHOT jar files created when I build MyFaces 1.2. Which ones should we integrated into Geronimo ?? I'm guessing these but would like some verification if possible. -- myfaces-api-1.2.0-SNAPSHOT -- myfaces-impl-1.2.0-SNAPSHOT -- myfaces-shared-core-3.0.0-SNAPSHOT -- myfaces-shared-impl-3.0.0-SNAPSHOT -- myfaces-shared-tomahawk-3.0.0-SNAPSHOT Thanks much Tim Wendy Smoak wrote: On 12/6/06, Tim McConnell [EMAIL PROTECTED] wrote: Hi, I've notice lately that there is a lot of activity around the MyFaces 1.2 release. I'm wondering if there is there a MyFaces 1.2 SNAPSHOT available in a maven repro that can be used for an upcoming Geronimo 2.0 Milestone ?? If so, where can I find it ?? If not, would it be too much to ask for one to be created so that we can incorporate it into our milestone build. Obviously, it doesn't have to be fully functional yet since we understand it's not fully implemented yet, but we're basically just trying to start integrating all of our dependencies for next year's 2.0 release. Thanks for any assistance I thought Continuum was set up to publish snapshots, but it was doing 'mvn install' instead of 'mvn deploy'. I changed it. That will get us part of the way there, unfortunately Continuum insists that 1.2 won't build, when it does work locally. I'll try to work on it this weekend. http://myfaces.zones.apache.org:8080/continuum/ Meanwhile, if someone who has a clean checkout of the 1.2 branch could do 'mvn deploy' that would help.
Re: MyFaces 1.2
That's wonderful. Thanks much . Wendy Smoak wrote: On 12/6/06, Tim McConnell [EMAIL PROTECTED] wrote: Thanks for the information Wendy. BTW, have another question. I see a number of SNAPSHOT jar files created when I build MyFaces 1.2. Which ones should we integrated into Geronimo ?? I'm guessing these but would like some verification if possible. -- myfaces-api-1.2.0-SNAPSHOT -- myfaces-impl-1.2.0-SNAPSHOT -- myfaces-shared-core-3.0.0-SNAPSHOT -- myfaces-shared-impl-3.0.0-SNAPSHOT -- myfaces-shared-tomahawk-3.0.0-SNAPSHOT You should just need the api and impl jars. Shared gets repackaged at build time, and Tomahawk is a custom component library.
JSR-252
Hi, I see that there are a number of Jira's opened with JSR-252 as the component. Does that mean there is a definitive (or even tentative) plan to implement the new specification for JSF 1.2 ?? If so, I'm really just trying to ascertain when to anticipate a MyFaces release based on JSR-252. Thanks much for any information. Tim
