Re: Proposal: Sundown Shale-Tiles
I brought this up, since the Shale developers might want to more carefully consider the decision to drop Tiles support along the way to MyFaces integration or at least consider how Tiles/JSF 1.2 support will be managed going forward under the MyFaces umbrella. It has been my experience that to get around the interleaving/interweaving problem---immediate vs. deferred expression evaluation---of JSP/JSF/Tiles it was necessary to modify existing Tiles View handlers. The experimental code, based on the Sun RI that I am using and posted previously resolves this problem apparently by using a new JSF 1.2 specific interweaving class. I consider this important, since I use Tiles and I want to and currently am using JSF 1.2, since it resolves the interweaving problem among other things. Granted, I could potentially move to Clay, but I came from Struts and I am familiar with Tiles and it does what I need it to do, especially the latest version. IHMO the current state of Tiles support in MyFaces and Shale acts as a barrier to Tiles adoption under JSF 1.2 which I hope is not intentional. Given the amount of effort that has been put into the latest Tiles version and its apparent strong support in the Struts community, it seems that it would be beneficial to refactor a Tiles view handler to support JSF 1.2 across multiple JSF implementations and yes I do know that I am asking for this support from a group of volunteers. I would do this myself and post it, but I don't believe that I quite have the detailed expertise to pull it off yet. -= Gregg =- Greg Reddin wrote: On Jan 2, 2008 6:25 PM, Gregg Leichtman [EMAIL PROTECTED] wrote: Does the MyFaces view handler support JSF 1.2? I'm ashamed to say I don't know what's changed in the ViewHandler API between 1.1 and 1.2. If there are changes I suspect the current view handler from MyFaces or Shale wouldn't be compatible, right? I think I've heard somewhere in MyFaces land that Tomahawk is not 1.2-compliant. I hope someone will chime in and clarify :-) Greg signature.asc Description: OpenPGP digital signature
Re: [FWD: [v1.0.4] shale-tiles and release notes (was Re: svn commit: r490857 ...)]
I believe that this is a good summary of future Shale dev intentions. It might be useful to put something similar to this message in, possibly, the Project Info section of the web site as a future direction blurb for users with links to/from the dependencies page. It seems that this would be useful info for users to know. Thanks to each of you for all the valuable info and the insight it provided. -= Gregg =- Craig McClanahan wrote: On 1/15/07, Greg Reddin [EMAIL PROTECTED] wrote: On 1/15/07, Kailas Lovlekar [EMAIL PROTECTED] wrote: Shale is listed at version 1.1.0 All the pom.xml files show 1.1.0-SNAPSHOT, not sure how 1.0.4 was derived for next release. I believe it's just an iteration. When we got 1.0.4 ready we renamed the trunk to 1.1.0-SNAPSHOT expecting that to be the next major release. That doesn't mean there won't be anymore 1.0.x releases, but I think it means they will take place in the 1.0 branch. That is correct. To summarize the state of things: * The website always shows the latest and greatest version of the website from the trunk (which is now targeted towards 1.1) * Version 1.0.4 is in the process of being released. One of the tasks along that way is a link (on the front page) to a static copy of the website as it was for that version. This is not done yet but still needs to be. * In the future, we're planning on two track development: - New features, in addition to bugfixes, go into the trunk targeting 1.1.x. - We have a branch for 1.0.x so we can do any needed emergency fixes to 1.0.4, without having to force the user to accept all of the new features on the trunk that might not be stable yet. - In general, you can assume that new features will *not* be backported from the trunk. The whole idea is that we can turn around very quickly on bugfix or security vulnerability issues that might come up, with disrupting existing applications that are using the latest released version. - When a 1.1.x release achieves feature completeness, the cycle will start again ... the trunk will switch to 1.2 or perhaps 2.0, and there will be a maintenance branch for 1.1. We're setting this approach up deliberately to avoid some of the long lead time for a release issues that have affected projects like Struts and MyFaces, where it was difficult to do bugfixes quickly because everything happened on the trunk (no branches). We aim to do better than that. Greg Craig signature.asc Description: OpenPGP digital signature
Re: [FWD: [v1.0.4] shale-tiles and release notes (was Re: svn commit: r490857 ...)]
I guess the thing that is most confusing to me is that on the project summary page and on the dependencies page: http://shale.apache.org/shale-tiles/project-summary.html http://shale.apache.org/shale-tiles/dependencies.html Shale is listed at version 1.1.0, but it appears that the dev group is getting ready to release version 1.0.4. I would have thought that the currently released and posted version on these web pages would be 1.0.3. Is this currently posted version number correct and if so why? I have not yet moved this discussion to the user forum, since I believe that this topic, possibly erroneously, is still pertinent to keeping things in synch for the next release that the dev group appears to be planning. -= Gregg =- Rahul Akolkar wrote: On 1/5/07, Gregg Leichtman [EMAIL PROTECTED] wrote: Additionally, note that the framework distribution (nightlies or release) contains all dependency jars in the lib folder Ok, that is _very_ useful (thanks, I had not noticed this and had been going out on my own for the past few months to try and match components up with Shale nightlies with various levels of success); however, when I go to the Tiles core download site at: http://people.apache.org/builds/struts/nightlies/tiles/ I find: snip-list/ None of the versioning above matches the versioning of the file tiles-core-2.0-r468346-SNAPSHOT.jar provided in the framework, so how can I correlate the two? Continue reading. snap/ Its in the snapshot repository (long, possible fragmented URL) that is used by the build: http://people.apache.org/repo/m2-snapshot-repository/org/apache/struts/tiles/tiles-core/ Its also available on the website, the dependency page for shale-tiles is here: http://shale.apache.org/shale-tiles/dependencies.html This is good also; however, I can't find any place on this page where it states which version of Shale these dependencies go to. I assume that since 1.0.3 is the currently released version of Shale, these dependencies apply to it, but that doesn't seem to be stated. If this is true, then I assume that tiles-core-2.0-r468346-SNAPSHOT.jar applies to Shale 1.0.3. Correct? If this is correct, maybe the dependencies page can have a blurb in it to state which version of Shale the dependencies apply to. Since the page is generated by Maven, maybe Maven makes this too hard to do. snip/ That version applies to (a probably soon to be out) Shale 1.0.4 or a recent nightly. For Shale 1.0.3, it wasn't pinned down to a specific svn revision (and your best bet is, again, to pick up the jar that would have come in the lib/ directory of the 1.0.3 framework distro). Your point about trying to correlate this information (especially for someone not used to Maven and its sites) is however well taken. (similarly for other modules -- for each module, the 'Project Documentation' section in the left side navbar has this, and other, information). I don't see anything relevant under the Project Documentation section. I do see sub-projects under Sub-Project Documentation, but these don't appear to supply versioning information. For example, the link http://shale.apache.org/shale-tiles/index.html for tiles. snip/ For example, the project summary has the version number of the artifact you're looking for: http://shale.apache.org/shale-tiles/project-summary.html If there are further questions, we should probably move this to the user list. -Rahul -= Gregg =- signature.asc Description: OpenPGP digital signature
Re: [FWD: [v1.0.4] shale-tiles and release notes (was Re: svn commit: r490857 ...)]
Additionally, note that the framework distribution (nightlies or release) contains all dependency jars in the lib folder Ok, that is _very_ useful (thanks, I had not noticed this and had been going out on my own for the past few months to try and match components up with Shale nightlies with various levels of success); however, when I go to the Tiles core download site at: http://people.apache.org/builds/struts/nightlies/tiles/ I find: tiles-core-2.0-SNAPSHOT-20061230.jar http://people.apache.org/builds/struts/nightlies/tiles/tiles-core-2.0-SNAPSHOT-20061230.jar 29-Dec-2006 17:13 129K Automated test builds tiles-core-2.0-SNAPSHOT-20061231.jar http://people.apache.org/builds/struts/nightlies/tiles/tiles-core-2.0-SNAPSHOT-20061231.jar 30-Dec-2006 17:22 129K Automated test builds tiles-core-2.0-SNAPSHOT-20070101.jar http://people.apache.org/builds/struts/nightlies/tiles/tiles-core-2.0-SNAPSHOT-20070101.jar 31-Dec-2006 17:09 129K Automated test builds tiles-core-2.0-SNAPSHOT-20070102.jar http://people.apache.org/builds/struts/nightlies/tiles/tiles-core-2.0-SNAPSHOT-20070102.jar 01-Jan-2007 17:14 129K Automated test builds tiles-core-2.0-SNAPSHOT-20070103.jar http://people.apache.org/builds/struts/nightlies/tiles/tiles-core-2.0-SNAPSHOT-20070103.jar 02-Jan-2007 17:10 129K Automated test builds tiles-core-2.0-SNAPSHOT-20070104.jar http://people.apache.org/builds/struts/nightlies/tiles/tiles-core-2.0-SNAPSHOT-20070104.jar 03-Jan-2007 17:15 130K Automated test builds tiles-core-2.0-SNAPSHOT-20070105.jar http://people.apache.org/builds/struts/nightlies/tiles/tiles-core-2.0-SNAPSHOT-20070105.jar 04-Jan-2007 17:13 130K Automated test builds None of the versioning above matches the versioning of the file tiles-core-2.0-r468346-SNAPSHOT.jar provided in the framework, so how can I correlate the two? Continue reading. Its also available on the website, the dependency page for shale-tiles is here: http://shale.apache.org/shale-tiles/dependencies.html This is good also; however, I can't find any place on this page where it states which version of Shale these dependencies go to. I assume that since 1.0.3 is the currently released version of Shale, these dependencies apply to it, but that doesn't seem to be stated. If this is true, then I assume that tiles-core-2.0-r468346-SNAPSHOT.jar applies to Shale 1.0.3. Correct? If this is correct, maybe the dependencies page can have a blurb in it to state which version of Shale the dependencies apply to. Since the page is generated by Maven, maybe Maven makes this too hard to do. (similarly for other modules -- for each module, the 'Project Documentation' section in the left side navbar has this, and other, information). I don't see anything relevant under the Project Documentation section. I do see sub-projects under Sub-Project Documentation, but these don't appear to supply versioning information. For example, the link http://shale.apache.org/shale-tiles/index.html for tiles. -= Gregg =- signature.asc Description: OpenPGP digital signature
Re: [FWD: [v1.0.4] shale-tiles and release notes (was Re: svn commit: r490857 ...)]
Just a suggestion. It would be helpful, to me at least, if you were to include within the release notes one or more snapshot version numbers of standalone Tiles, one or more version numbers of Spring and one or more version numbers of other targeted components that work with Shale with which you the development group believes v1.0.4 appears to work. I realize that items like Tiles in sandboxes are fast moving targets, but it helps us users avoid having to do a lot of trial and error just to find a single combination of components that works. If we have one working set, substituting different components one at a time using trial and error during component upgrades is far less burdensome that not knowing anything about what works together. -= Gregg =- Rahul Akolkar wrote: On 12/29/06, Greg Reddin [EMAIL PROTECTED] wrote: From: Rahul Akolkar [EMAIL PROTECTED] Date: Thu, December 28, 2006 4:56 pm To: commits@shale.apache.org The above projected quality paragraph needs to be updated to reflect the current sentiment. Of the two items in that list, 1.0.4 will address most of the dialog issues (so I've removed that). Someone more familiar with shale-tiles (and changes implied by going TLP) should update the above paragraph in the release notes. TIA. The TLP hasn't changed the status of Tiles just yet. Tiles will still be a snapshot for a while because it will take some time to get the TLP infrastructure set up. snip/ Thanks, the related bits are in section 1 and 4 of the release notes -- you're welcome (as is everyone else) to tweak the wording (long, possibly fragmented URL): http://svn.apache.org/repos/asf/shale/framework/trunk/src/site/resources/docs/release-notes-1.0.4.html -Rahul Greg signature.asc Description: OpenPGP digital signature
Re: Shale-related Tiles 2 issue - Compatibility
I did a search on the net previous to my post and the messages I found seemed to indicate that there were problems in using MyFaces with JSF 1.2 since MyFaces stable distributions don't support JSF 1.2; however, it was impossible for me to determine what versions of MyFaces and I did not find mention of using Tomahawk specifically with the RI. I just assumed, possibly incorrectly, that Tomahawk would be dependent upon MyFaces and MyFaces is not compatible with JSF 1.2 RI. Are the nightly builds of MyFaces compatible with the JSF 1.2 RI at this point? Is Tomahawk independent of MyFaces? -= Gregg =- Greg Reddin wrote: On Oct 3, 2006, at 7:01 PM, Gregg Leichtman wrote: I'm in the process of setting up to test this. I should have an answer to this by the end of the week. I was hoping not to have to move to the RI, because I wanted access to the MyFaces extensions. Sorry for my ignorance, but it seems like I've seen messages from people who are using the RI with MyFaces extensions like Tomahawk, etc. Have you tried that at all or have you maybe researched it more than me and found it to not be viable? Greg signature.asc Description: OpenPGP digital signature
