[jira] Updated: (TOMAHAWK-652) CSS Fails validation.
[ http://issues.apache.org/jira/browse/TOMAHAWK-652?page=all ] Paul Spencer updated TOMAHAWK-652: -- Status: Patch Available (was: Open) CSS Fails validation. - Key: TOMAHAWK-652 URL: http://issues.apache.org/jira/browse/TOMAHAWK-652 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Affects Versions: 1.1.4-SNAPSHOT, 1.1.3, 1.1.5-SNAPSHOT Reporter: Paul Spencer The CSS validator [1] report 2 errors in the stylesheet, defaultStyles.css, used by TabbedPane. * Line: 40 Context : .myFaces_panelTabbedPane_disabledHeaderCell label Invalid number : cursor normal is not a cursor value : normal * Line: 53 Context : .myFaces_panelTabbedPane_subHeaderCell Invalid number : line-height Parse Error - [empty string] The link belows is the actual file in SVN: http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/tabbedpane/resource/defaultStyles.css?revision=407208content-type=text%2Fplainpathrev=407208 [1] http://jigsaw.w3.org/css-validator/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TOMAHAWK-652) CSS Fails validation.
[ http://issues.apache.org/jira/browse/TOMAHAWK-652?page=all ] Paul Spencer updated TOMAHAWK-652: -- Status: Patch Available (was: Open) CSS Fails validation. - Key: TOMAHAWK-652 URL: http://issues.apache.org/jira/browse/TOMAHAWK-652 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Affects Versions: 1.1.4-SNAPSHOT, 1.1.3, 1.1.5-SNAPSHOT Reporter: Paul Spencer The CSS validator [1] report 2 errors in the stylesheet, defaultStyles.css, used by TabbedPane. * Line: 40 Context : .myFaces_panelTabbedPane_disabledHeaderCell label Invalid number : cursor normal is not a cursor value : normal * Line: 53 Context : .myFaces_panelTabbedPane_subHeaderCell Invalid number : line-height Parse Error - [empty string] The link belows is the actual file in SVN: http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/tabbedpane/resource/defaultStyles.css?revision=407208content-type=text%2Fplainpathrev=407208 [1] http://jigsaw.w3.org/css-validator/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TOMAHAWK-652) CSS Fails validation.
[ http://issues.apache.org/jira/browse/TOMAHAWK-652?page=all ] Paul Spencer updated TOMAHAWK-652: -- Status: Open (was: Patch Available) CSS Fails validation. - Key: TOMAHAWK-652 URL: http://issues.apache.org/jira/browse/TOMAHAWK-652 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Affects Versions: 1.1.4-SNAPSHOT, 1.1.3, 1.1.5-SNAPSHOT Reporter: Paul Spencer The CSS validator [1] report 2 errors in the stylesheet, defaultStyles.css, used by TabbedPane. * Line: 40 Context : .myFaces_panelTabbedPane_disabledHeaderCell label Invalid number : cursor normal is not a cursor value : normal * Line: 53 Context : .myFaces_panelTabbedPane_subHeaderCell Invalid number : line-height Parse Error - [empty string] The link belows is the actual file in SVN: http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/tabbedpane/resource/defaultStyles.css?revision=407208content-type=text%2Fplainpathrev=407208 [1] http://jigsaw.w3.org/css-validator/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TOMAHAWK-652) CSS Fails validation.
[ http://issues.apache.org/jira/browse/TOMAHAWK-652?page=all ] Paul Spencer updated TOMAHAWK-652: -- Status: Open (was: Patch Available) CSS Fails validation. - Key: TOMAHAWK-652 URL: http://issues.apache.org/jira/browse/TOMAHAWK-652 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Affects Versions: 1.1.4-SNAPSHOT, 1.1.3, 1.1.5-SNAPSHOT Reporter: Paul Spencer The CSS validator [1] report 2 errors in the stylesheet, defaultStyles.css, used by TabbedPane. * Line: 40 Context : .myFaces_panelTabbedPane_disabledHeaderCell label Invalid number : cursor normal is not a cursor value : normal * Line: 53 Context : .myFaces_panelTabbedPane_subHeaderCell Invalid number : line-height Parse Error - [empty string] The link belows is the actual file in SVN: http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/tabbedpane/resource/defaultStyles.css?revision=407208content-type=text%2Fplainpathrev=407208 [1] http://jigsaw.w3.org/css-validator/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TOMAHAWK-652) CSS Fails validation.
[ http://issues.apache.org/jira/browse/TOMAHAWK-652?page=all ] Paul Spencer updated TOMAHAWK-652: -- Status: Patch Available (was: Open) CSS Fails validation. - Key: TOMAHAWK-652 URL: http://issues.apache.org/jira/browse/TOMAHAWK-652 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Affects Versions: 1.1.4-SNAPSHOT, 1.1.3, 1.1.5-SNAPSHOT Reporter: Paul Spencer Attachments: patch.txt The CSS validator [1] report 2 errors in the stylesheet, defaultStyles.css, used by TabbedPane. * Line: 40 Context : .myFaces_panelTabbedPane_disabledHeaderCell label Invalid number : cursor normal is not a cursor value : normal * Line: 53 Context : .myFaces_panelTabbedPane_subHeaderCell Invalid number : line-height Parse Error - [empty string] The link belows is the actual file in SVN: http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/tabbedpane/resource/defaultStyles.css?revision=407208content-type=text%2Fplainpathrev=407208 [1] http://jigsaw.w3.org/css-validator/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-666) Background show between the tab and the active panel
Background show between the tab and the active panel Key: TOMAHAWK-666 URL: http://issues.apache.org/jira/browse/TOMAHAWK-666 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Affects Versions: 1.1.3, 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: Paul Spencer The background show through between the active tab and the active panel. When the table background is different then the tab and panel background the tab does not appear to be connected to the panel. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-666) Background show between the tab and the active panel
[ http://issues.apache.org/jira/browse/TOMAHAWK-666?page=comments#action_12433705 ] Paul Spencer commented on TOMAHAWK-666: --- The problem always appears when serversSideSwitch=true. WIth serverSideSwitch='false' the problem appears in IE when the table is initally displayed. Background show between the tab and the active panel Key: TOMAHAWK-666 URL: http://issues.apache.org/jira/browse/TOMAHAWK-666 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Affects Versions: 1.1.4-SNAPSHOT, 1.1.3, 1.1.5-SNAPSHOT Reporter: Paul Spencer The background show through between the active tab and the active panel. When the table background is different then the tab and panel background the tab does not appear to be connected to the panel. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-1406) Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1
Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1 --- Key: MYFACES-1406 URL: http://issues.apache.org/jira/browse/MYFACES-1406 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 1.1.5-SNAPSHOT Reporter: Paul Spencer Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1. Their are 2 problems here: 1) The dependency group is myfaces instead of org.apache.myfaces.core 2) The version number is wrong. In many places this problem is minimized by the fact that the depenency is marked as provided. I notices the problem why using eclipse. Eclipse was trying to use the 1.1.1 version of the API even though I was working with the 1.1.5-SNAPSHOT . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1406) Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1
[ http://issues.apache.org/jira/browse/MYFACES-1406?page=comments#action_12433709 ] Wendy Smoak commented on MYFACES-1406: -- Core has a dependency on Shared. myfaces/core/impl/pom.xml: artifactItem groupIdorg.apache.myfaces.shared/groupId artifactIdmyfaces-shared-impl/artifactId version2.0.4-SNAPSHOT/version /artifactItem Therefore, Shared cannot depend on the current snapshot of Core or we will have a circular dependency. (Note that it's in a plugin execution and not a normal dependency, so Maven won't catch it during dependency resolution.) The JSF 1.1 API hasn't changed, so it shouldn't matter whether myfaces-impl builds against 1.1.1 or 1.1.5-SNAPSHOT (or against the API jar from the reference implementation, for that matter.) I'm not as opposed to this one, but I don't think it's necessary... and the fewer snapshot dependencies the better. The situation may improve once 1.1.4 is available, because it will be in the same groupId as the current snapshot. Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1 --- Key: MYFACES-1406 URL: http://issues.apache.org/jira/browse/MYFACES-1406 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 1.1.5-SNAPSHOT Reporter: Paul Spencer Attachments: patch-to-core.txt, patch-to-shared.txt Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1. Their are 2 problems here: 1) The dependency group is myfaces instead of org.apache.myfaces.core 2) The version number is wrong. In many places this problem is minimized by the fact that the depenency is marked as provided. I notices the problem why using eclipse. Eclipse was trying to use the 1.1.1 version of the API even though I was working with the 1.1.5-SNAPSHOT . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: MyFaces Core 1.1.4 - STATUS
On 9/8/06, Wendy Smoak [EMAIL PROTECTED] wrote: I'm tentatively planning to try again on Sunday. I'm working on this now. I'm on GTalk, Skype, etc., and on IRC on chat.freenode.net #myfaces (not an official channel, but joining it seems to have created it.) More info on the release plan: http://wiki.apache.org/myfaces/CoreRelease114 And here, where I'll keep notes on what I'm doing: http://wiki.wsmoak.net/cgi-bin/wiki.pl?MyFacesCore114 -- Wendy
Re: GENERATED CODE BEGIN (do not modify!)
L.S., A while ago, I have been doing a few things for the code generator (MYFACES-1284 in JIRA) but at that time, it was suggested by Manfred to wait with cleaning up all manual changes in the generated code blocks until release 1.1.x was done. You're not doing anything wrong, there are in fact lots of changes between the code generated and the code that is currently in SVN. It's even worse for the Tomahawk components. Personally, I see little added value in the call to _ComponentUtils.getStringValue() generated, so I would suggest to change the code generator to generate the code currently in SVN. I can create a patch for this tomorrow and add it to the JIRA issue mentioned before. When that gets applied, it should get us already one step closer to bringing the generated code back in sync with SVN. Secondly, I know Trinidad uses a code generator, perhaps Tobago does so too. Does anyone have an idea what they generate and how they do it? It might be a good idea to look if any of the code generators in these other Myfaces subprojects have some extra features to offer on top of what already exists. It might give us a way to have more boilerplate code generated quickly, as Werner Punz was asking earlier today. Gert Vanthienen [EMAIL PROTECTED] L Frohman wrote: I tried the codegenerator, and it did not produce the results that are in the existing code: A file compare gives me a lot of: return vb != null ? _ComponentUtils.getStringValue(getFacesContext(), vb) : null; --- return vb != null ? (String)vb.getValue(getFacesContext()) : null; is existing svn code is generated code Am I doing something wrong? -Original Message- From: Manfred Geiler [mailto:[EMAIL PROTECTED] Sent: Thursday, September 07, 2006 4:11 AM To: MyFaces Development Subject: Re: GENERATED CODE BEGIN (do not modify!) Dennis, Lance, I am indeed of the opinion that is is NOT OK to modify this generated code parts. Code generation will get importance again when we do the 1.2 port. And: Code generation is still important and convenient for coding new tomahawk components. Well, nobody seems to use it by now. Reason might be (no, I'm sure it IS) the lack of docs. Yes, Lance, you are right, there are no docs. Mea culpa. And in defense I can not even say it's self-explaining. Because it is not! ;-) Ok, I give you a very short intro: Codegenerator can be used by doing a mvn clean install -Pregenerate-component-code You can try it in core/api for instance. Base for the generation of these code parts is an according xml file that looks like this: http://svn.apache.org/viewvc/myfaces/core/trunk/api/src/main/java/javax/face s/component/html/HtmlCommandButton.xml?view=markup and sits in the same src dir as the component's java file. (which is nonsense and should be in a config folder according to the maven standard dir layout, of course) There are some quirks: No dtd or xsd, and so on But: it works! And it did a great job in the early days of MyFaces. HTH and thanks for your interest in this nostalgic thingy :-) Manfred On 9/5/06, L Frohman [EMAIL PROTECTED] wrote: Thanks, There is a codegenerator under build-tools under maven. No documentation? (stupid question?) -Original Message- From: Dennis Byrne [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 05, 2006 12:11 PM To: MyFaces Development Subject: Re: GENERATED CODE BEGIN (do not modify!) Large parts of the original code base were generated. The generator has recently been committed. Check svn ... I forget the name, but it is a seperate sub project. Is anyone else of the opinion that it is now OK to modify this code? One doesn't have to look to far to find plenty of undocumented cases where many of us have done this, and for good reasons. Dennis Byrne -Original Message- From: L Frohman [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 5, 2006 03:00 PM To: ''MyFaces Development'' Subject: re: GENERATED CODE BEGIN (do not modify!) In several of the myfaces components, there is code marked GENERATED CODE BEGIN (do not modify!) (in particular org.apache.myfaces.component.html.ext.HtmlPanelGroup) How is this generated?
Re: ann/discussion:moving core dojo to tomahawk
Sounds good to me. After migrating some dojo sandbox components to tomahawk we should also start getting rid of the legacy javaScript code in many of the tomahawk components. Maybe this is not a trivial task; e.g. calendar has much plain js inside, replacing it with a widget also changes the visualization of the client representation. The changing should have as less impacts on the users as possible, they rely on the current states of the stable components. We will see our business if we get nearly toward this task; Maybe first getting rid of the helper functions (which should have no side effects) and then let`s think about the complete replacements. Let me know if i can help out in case of the upcoming migration, cheers, Gerald On 9/9/06, Werner Punz [EMAIL PROTECTED] wrote: Since this has been high on my list and i am currently in the finishing stages for the core dojo stuff (writing documentation as we speak) it has been planned that we move the core dojo stuff, which is for now, the dojo core code, the dojoInitializer the dojo utils and the dojo extensions into tomahawk. After that I want to push some of the dojo based sandbox stuff forward into tom asap, due to constant user requests. I will fullfill the promotion criteria like docs etc... for this, but I wanted to give an upfront warning that the move of the core libs is imminent and will be voted on soon. As for the stability of the interfaces. There only have been additions regarding ADF comptabibility in the DojoUtils and one or two small bugfixes in the recent past. I assume that is enough for interface stability. The docs for the dojoInitializer are in the works and will be committed tomorrow, the working examples are in place and will be linked more extensively around the same period of time. So my plan is to get the thing up into Tom by around next weekend. Once the docs are done from my side and if there are no severe objections. After that we should move on to push some of the already more than a handful of sandbox components into Tom, to clean up the sandbox. The big showstopper has been Dojo, which had to be upgraded to 0.3.1 and the lack to time to get the core into the tomahawk. As for the future plans, as time permits I will push for the next stable dojo, after one grace period of 1-2 months after a stable dojo release. This is for two reasons, first to check whether showstoppers have arrived in the dojo release, secondly to give us a grace period to adjust our codebase and fix our components upfront, to make the transitions as seamless as possible. Also in the long run we will have to sync our release cycles of dojo releases somehow with the Sun guys as they move towards dojo as well and I will have to try to figure out how to get the codebase itself out of the code and push it into the build process more dynamically so that we do not have this huge source grave in our resources (weblets or something else probably is the way to go) But as time presses due to user demands, I think those are issues which have to be considered to be long term goals the short term goal is to push dojo up and then try to get components from the sandbox into Tom. -- Gerald Müllan Schelleingasse 2/11 1040 Vienna, Austria 0043 699 11772506 [EMAIL PROTECTED]
Shared and API circular dependency, related to (MYFACES-1406)
Wendy, The circular dependency between the API and shared projects is a little concerning. Is this something that can be easily be fixed? Since the dependency is marked as provided, does this eliminate the circular depenency issues in Maven? I use Eclipse and the Maven Eclipse plugin to generated the Eclipse project files. Currently the shared projects reference the 1.1.1 version of the API. The means the debuggers and the other tools in the Eclipse are using 1.1.1 API. Like you said the API does not change, but use of an older version it can be confusing. Paul Spencer Wendy Smoak (JIRA) wrote: [ http://issues.apache.org/jira/browse/MYFACES-1406?page=comments#action_12433709 ] Wendy Smoak commented on MYFACES-1406: -- Core has a dependency on Shared. myfaces/core/impl/pom.xml: artifactItem groupIdorg.apache.myfaces.shared/groupId artifactIdmyfaces-shared-impl/artifactId version2.0.4-SNAPSHOT/version /artifactItem Therefore, Shared cannot depend on the current snapshot of Core or we will have a circular dependency. (Note that it's in a plugin execution and not a normal dependency, so Maven won't catch it during dependency resolution.) The JSF 1.1 API hasn't changed, so it shouldn't matter whether myfaces-impl builds against 1.1.1 or 1.1.5-SNAPSHOT (or against the API jar from the reference implementation, for that matter.) I'm not as opposed to this one, but I don't think it's necessary... and the fewer snapshot dependencies the better. The situation may improve once 1.1.4 is available, because it will be in the same groupId as the current snapshot. Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1 --- Key: MYFACES-1406 URL: http://issues.apache.org/jira/browse/MYFACES-1406 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 1.1.5-SNAPSHOT Reporter: Paul Spencer Attachments: patch-to-core.txt, patch-to-shared.txt Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1. Their are 2 problems here: 1) The dependency group is myfaces instead of org.apache.myfaces.core 2) The version number is wrong. In many places this problem is minimized by the fact that the depenency is marked as provided. I notices the problem why using eclipse. Eclipse was trying to use the 1.1.1 version of the API even though I was working with the 1.1.5-SNAPSHOT .
Re: [jira] Commented: (MYFACES-1406) Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1
Wendy, Should the patch to core be applied? Paul Spencer Wendy Smoak (JIRA) wrote: [ http://issues.apache.org/jira/browse/MYFACES-1406?page=comments#action_12433709 ] Wendy Smoak commented on MYFACES-1406: -- Core has a dependency on Shared. myfaces/core/impl/pom.xml: artifactItem groupIdorg.apache.myfaces.shared/groupId artifactIdmyfaces-shared-impl/artifactId version2.0.4-SNAPSHOT/version /artifactItem Therefore, Shared cannot depend on the current snapshot of Core or we will have a circular dependency. (Note that it's in a plugin execution and not a normal dependency, so Maven won't catch it during dependency resolution.) The JSF 1.1 API hasn't changed, so it shouldn't matter whether myfaces-impl builds against 1.1.1 or 1.1.5-SNAPSHOT (or against the API jar from the reference implementation, for that matter.) I'm not as opposed to this one, but I don't think it's necessary... and the fewer snapshot dependencies the better. The situation may improve once 1.1.4 is available, because it will be in the same groupId as the current snapshot. Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1 --- Key: MYFACES-1406 URL: http://issues.apache.org/jira/browse/MYFACES-1406 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 1.1.5-SNAPSHOT Reporter: Paul Spencer Attachments: patch-to-core.txt, patch-to-shared.txt Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1. Their are 2 problems here: 1) The dependency group is myfaces instead of org.apache.myfaces.core 2) The version number is wrong. In many places this problem is minimized by the fact that the depenency is marked as provided. I notices the problem why using eclipse. Eclipse was trying to use the 1.1.1 version of the API even though I was working with the 1.1.5-SNAPSHOT .
Re: MyFaces Core 1.1.4 - STATUS
The Core 1.1.4 distribution, with signatures, is available for testing: http://people.apache.org/builds/myfaces/core-1.1.4 Please see the release plan page for more information, including a link to the JIRA release notes and details on how to configure your Maven 2 project to use the staging repository: http://wiki.apache.org/myfaces/CoreRelease114 I tested the 1.1.4 jars with the 'simple' example app in Tomcat 5.5, and the Selenium tests all pass (which means that the add numbers form, and the tree2 and popup components are working.) I'll start a vote after we know it passes the TCK. (Dennis? This should be the last time for 1.1.4. :) ) Thanks, -- Wendy
[jira] Commented: (MYFACES-1406) Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1
[ http://issues.apache.org/jira/browse/MYFACES-1406?page=comments#action_12433761 ] Wendy Smoak commented on MYFACES-1406: -- Related thread: http://www.nabble.com/Shared-and-API-circular-dependency%2C-related-to-%28MYFACES-1406%29-p6239070.html Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1 --- Key: MYFACES-1406 URL: http://issues.apache.org/jira/browse/MYFACES-1406 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 1.1.5-SNAPSHOT Reporter: Paul Spencer Attachments: patch-to-core.txt, patch-to-shared.txt Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1. Their are 2 problems here: 1) The dependency group is myfaces instead of org.apache.myfaces.core 2) The version number is wrong. In many places this problem is minimized by the fact that the depenency is marked as provided. I notices the problem why using eclipse. Eclipse was trying to use the 1.1.1 version of the API even though I was working with the 1.1.5-SNAPSHOT . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
