Re: Questions about the release instructions
Ross Gardler wrote: Ferdinand Soethe wrote: DISCLAIMER I have never done a release so I'm only giving you my interpretation of the document. Authorative answers will come from elsewhere if I have got something wrong. A bit of background might help. Jeff Turner did the releases up to forrest-0.5 and many thanks to him for starting this text file. Then Jeff moved on to other things. For the 0.6 release i practiced many times beforehand (my first ever release) and Dave Brondsema helped. We refined thoses notes as we went. This time it sounds like Ferdinand is offering to help. That is great, because we need more people to understand it and not rely on any particular people. Ferdinand, the procedure assumes that you are familiar with login to the Apache server, familiar with using SVN, and building the Forrest website, etc. These notes do not attempt to describe all the background. I reckon it would be better that i do the process and that Ferdinand helps me or at least comes along for part of the ride. However, if you don't feel comfortable then i will do it by myself and we can find someone to help next time. As you can see, it is quite a big job. I definitely need help at the stage of creating the Windows .zip and MD5/PGP. - Create a new file, etc/RELEASE-NOTES-x.y.txt, where x.y is the version currently being released. It is best to copy an earlier RELEASE-NOTES file, to keep a common layout. In this file, provide a summary of changes, and check for general accuracy. Scan the status.xml/changes and the Roadmap via the issues tracker, to find the important issues. Ross: Is this the part that you have automated? If so, can you pls provide me with new instructions. Yes: http://marc.theaimsgroup.com/?l=forrest-devm=111695995215534w=2 Be aware of http://issues.apache.org/jira/browse/FOR-514?page=all, however, this patch need not be applied for our release (since the current behaviour is OK for our limited use case). The new ability might assist, but we still need the RELEASE-NOTES-0.7.txt file. - Check out a fresh copy from SVN to make sure you have no local modifications, especially those that might be hidden by svn:ignore settings. Alternatively, run 'svn st --no-ignore' and delete any extra files. I don't understand this step. - Wouldn't this have to come as a very first step before the I start editing the release numbers? yes - When do I commit the changes to the release numbers? I didn't read the whole process, doens't it say something about creating a branch? If that is the case then you can commit anytime on the branch. I'd commit the trunk changes when everything has been approved, just before tagging the release (assuming we do that) The way that we did it last time is what is shown in RELEASE_NOTES.txt in the specified order. We tweaked the version numbers on the trunk, (i did a stack of practice runs at this stage before committing anything), created the branch, rolled the releases, ask people to test those during the 7-day window, then created the SVN tag. A dilemma occurs if there need to be fixes during the code-freeze. I gather that we need to vote on the actual release files, not just on our own copy of the trunk at the time. So if there are necessary changes, no matter how small, then i presume we need to patch both trunk and branch, then roll the releases again. - what exactly is to be done? = run 'svn st --no-ignore' = delete any extra files. What extra files? this is an alternative approach, but it could be error prone. I'd go with a clean checkout The extra files refers to anything that you might have added/changed in your local copy. They must not be packed with the release. It must be a pristine copy of the current trunk. - Set your Java version to be the lowest specified of our supported versions. Where is the definitive info on the supported versions? The FAQ says we need Java 1.4 or better. Does that mean it has to be 1.4.0 or can it be 1.4.x 1.4.0 Oooh, glad you asked that question. I was just going to use 1.4.1 Last time i did not use 1.3.0 rather 1.3.1 How do I 'set my java' to it? Install and adjust environment settings? Which ones are required? JAVA_HOME - Run 'build release-dist' to generate the distributions. - Two archives are created: apache-forrest-X.Y.tar.gz apache-forrest-X.Y.zip I only have a windows machine. So this step needs to be done on what? Linux, Unix, ??? Linux is just fins - you'll have to ask someone to do this build for you. I will do the UNIX build, you can do the Windows build. - Repeat that on a Windows machine. - Use the .tar.gz from the UNIX machine and .zip from the Windows machine. - In that way, SVN will ensure correct line-endings on all text files. Well you can do this, you will need Not sure what Ross' unfinished statement is. - Test the actual distribution on various
Re: [SUMMARY] Re: [PROPOSAL] A CMS for our Docs
David Crossley wrote: Ross Gardler wrote: ... Does this sound OK? It sounds brilliant. Indeed! The part that i like most is that each project is focussing on their own tools, we are not duplicating, and we are collaborating. David, it seems Ross cracked open the coconut [1] and we now have opensource nirvana. Cool beans! :-) [1] Since sayings are so different from place to place, I am inventing my own, so all will be equally disoriented ;-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
Gregor J. Rothfuss wrote: Ross Gardler wrote: OK, along the same theme of quick hacks I've put a simple demo together for you. To see it you need to checkout the locationmap_branch of Forrest. Seed a fresh site, do forrest run and look at the locaitonmap sample (last item in the samples menu). cool, seems to work fine: http://greg.abstrakt.ch/gallery/lenya/lenya_in_forrest There are a few things to note here: For a) you could have a look at the Daisy plugin (in the whiteboard of the locationmap branch). This provides pre and post filters to documents retrieved from daisy for doing things like URL rewriting and adding additional content (such as a disclaimer that the content is from a remote site, a license, a link back to the edit page for the document, that kind of thing). I suspect that the way I am doing this stuff will change when I find the time to get to grips with views. Although a long way from perfect I hope this is enough to illustrate how to do the integration (see I told you it was easy with the locationmap :-)) so initially, people could write documents in lenya, publish them, and then head over to forrest(bot?) to slurp all these pages in? the precise workflow will of course have to be worked out. Precisely. With a longer term goal of having Lenya writing to SVN so that we can also work offline in our preferred editing tools. Ross
old skins leather-dev and corium?
There are two skins of uncertain status: leather-dev and corium. Are they part of the Views now and we don't need them any more? They are not listed when we do 'forrest available-skins'. If they are not needed, then can we remove them, as i reckon they will confuse new users. Alternatively we could put a README.txt in that directory and hope that people read it. --David
Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
Gregor J. Rothfuss wrote: ... so initially, people could write documents in lenya, publish them, and then head over to forrest(bot?) to slurp all these pages in? My personal view is not to use the Forrestbot, but to mod_proxy/mod_cache a live Forrest instance that gets files from a published Lenya pubblication. In this way, publishing in Lenya is the only step needed to... publish :-) The Forrestbot is still needed though for the projects that do not use Lenya, and for the creation of daily site tarballs that can be used to get the site back up quickly in case of problems. Aditionally, what we would need is just to add an _edit_ link to each Forrest page that points to the url Lenya uses for editing. - ~ - Looking at the Doco document [1] I see that Lenya and Forrest are not directly interacting, as both talk to a common repository. What do you think about this architecture, is it really needed? I'm not sure it's *that* different from asking Lenya to get the docs for us, as it's a simple URL request. Basically, Lenya would be doing what the SLIDE+LENYA combo does in the graphic, thus removing the need for DASL that only Slide at Apache has, making us use Subversion. What remains to do are diffs. I'm not sure that the mail workflow is something we really need ATM. IMHO just adding editors that cannot publish, along with diffs, is something that gives us enough control. [1] http://wiki.apache.org/cocoon/Doco -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Questions about the release instructions
David Crossley wrote: Ross Gardler wrote: Ferdinand Soethe wrote: ... - Create a new file, etc/RELEASE-NOTES-x.y.txt, where x.y is the version currently being released. It is best to copy an earlier RELEASE-NOTES file, to keep a common layout. In this file, provide a summary of changes, and check for general accuracy. Scan the status.xml/changes and the Roadmap via the issues tracker, to find the important issues. Ross: Is this the part that you have automated? If so, can you pls provide me with new instructions. Yes: http://marc.theaimsgroup.com/?l=forrest-devm=111695995215534w=2 Be aware of http://issues.apache.org/jira/browse/FOR-514?page=all, however, this patch need not be applied for our release (since the current behaviour is OK for our limited use case). The new ability might assist, but we still need the RELEASE-NOTES-0.7.txt file. cd FORREST_HOME/site-author forrest run http://localhost:/releaseNotes_0.7-dev.txt What's missing from this document, I'll fix it while you folk work on other things. (note when the version number in status.xml has been changed then request http://localhost:/releaseNotes_0.7.txt, the warning about developer version will go and the version numbers will be right) ... - Repeat that on a Windows machine. - Use the .tar.gz from the UNIX machine and .zip from the Windows machine. - In that way, SVN will ensure correct line-endings on all text files. Well you can do this, you will need Not sure what Ross' unfinished statement is. I think I fell asleep at the keyboard at that point. I have no idea what I was saying. :-( As my grandfather used to say, if you've forgotten it then it wasn't important, but I think he may have forgotten what its like to have a six month child by then ;-) Ross
Re: Questions about the release instructions
David Crossley wrote: Ross, are you able to explain what needs to happen with the plugins at release-time. I mean do they all need to have -0.7 appended to the names of the zip files? Blast I forgot that entirely (again!). Yes we need two zipped versions, a pluginname-0.7.zip and a pluginname-0.8-dev.zip The system will then download the correct version for the currently installed version of Forrest. This will allow us to have a separate release cycle for plugins, if we deploy from a 0.8-dev version of Forrest then we will have the 0.8-dev zip file. However, now I write that down I don't like it because there is no distinction between a 0.1 version of a plugin for Forrest 0.7 and a 1.0 version of a plugin for Forrest 1.0 (for example) How about I change it to put the plugins in a directory so we have: 0.7/plugingOne-0.1.zip 0.7/plugingTwo-0.2.zip 0.8-dev/pluginOne-0.2-dev.zip 0.8-dev/plugingTwo-0.2.zip We only allow *-dev plugins in the current *-dev branch of Forrest We can worry about the release process for plugins after this release (just get them out there for 0.7, we can blow the trumpet on subsequent upgrade releases) Do we need to add something to our RELEASE_BOTES.txt file? Yes, a section on plugins with a link to the plugins page, I'll add to project-info plugin Does someone need to tweak the build file? Yes, leave it with me, I'll implement the above with whatever modifications people think we need. Ross
Re: Questions about the release instructions
Ross Gardler wrote: David Crossley wrote: Ross Gardler wrote: The new ability might assist, but we still need the RELEASE-NOTES-0.7.txt file. cd FORREST_HOME/site-author forrest run http://localhost:/releaseNotes_0.7-dev.txt What's missing from this document, I'll fix it while you folk work on other things. (note when the version number in status.xml has been changed then request http://localhost:/releaseNotes_0.7.txt, the warning about developer version will go and the version numbers will be right) The trouble is (and this is why i have been saying lets stick with the old manual method for now) that the build system grabs a copy of the file RELEASE-NOTES-0.7.txt and packs it into the top-level of the distribution. I don't feel like fiddling with the build system at this stage. There is plenty more important to concentrate on. --David
Re: svn commit: r189541 - /forrest/trunk/site-author/status.xml
[EMAIL PROTECTED] wrote: Author: crossley Date: Wed Jun 8 00:29:42 2005 New Revision: 189541 URL: http://svn.apache.org/viewcvs?rev=189541view=rev Log: Add missing @type attribute for one entry. sorry, I was testing jedit for editing status. Do you think that this attribute should be marked as required? Cheers, cheche
Re: Questions about the release instructions
David Crossley wrote: This time it sounds like Ferdinand is offering to help. Yes, I'll try. The reason I didn't say so before asking the questions was that I want to fully understand what I have to do before I commit myself to doing it ... That is great, because we need more people to understand it and not rely on any particular people. I was more thinking of spreading the nasty admin work on more shoulders ... Ferdinand, the procedure assumes that you are familiar with login to the Apache server, familiar with using SVN, and building the Forrest website, etc. These notes do not attempt to describe all the background. This is always my problem coming from a non-unix, non-open-source, non-whoknowswhatelse background. The learning curve is rather steep ... I reckon it would be better that i do the process and that Ferdinand helps me or at least comes along for part of the ride. Lazy as I am, I wouldn't mind that at all. Although, in order to really learn it, I'd probably better do it and ask you for help where I get stuck. A first step would be to update the instructions before i start. Anybody mind if I update them to show more details for people w/o that background? -- Ferdinand Soethe
Re: Questions about the release instructions
Ferdinand Soethe wrote: David Crossley wrote: ... A first step would be to update the instructions before i start. Anybody mind if I update them to show more details for people w/o that background? Mind, I hate doing those kinds of jobs, please be my guest. (note David already did some updates based on this thread) Ross
Re: [SUMMARY] Re: [PROPOSAL] A CMS for our Docs
Nicola Ken Barozzi wrote: David Crossley wrote: Ross Gardler wrote: ... Does this sound OK? It sounds brilliant. Indeed! The part that i like most is that each project is focussing on their own tools, we are not duplicating, and we are collaborating. David, it seems Ross cracked open the coconut [1] and we now have opensource nirvana. Cool beans! :-) [1] Since sayings are so different from place to place, I am inventing my own, so all will be equally disoriented ;-) Yes, i do get your drift (i.e. know what you mean). Hey Ross, do coconut milk and Whiskey mix? If so then i'll buy you one or two at ApacheCon. If not, then still, name your poison. --David
Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
Nicola Ken Barozzi wrote: Gregor J. Rothfuss wrote: ... so initially, people could write documents in lenya, publish them, and then head over to forrest(bot?) to slurp all these pages in? My personal view is not to use the Forrestbot, but to mod_proxy/mod_cache a live Forrest instance that gets files from a published Lenya pubblication. In this way, publishing in Lenya is the only step needed to... publish :-) OK - as long as someone shows me how when the time comes. This would mean published docs in Lenya that are already *approved* for publication in the final docs would automatically appear. New published docs in lenya would need adding to the relevant site.xml for the real docs, this is the point at which we bring order to the chaos (the http://www.answers.com order to the http://www.wikipedia.org chaos) Aditionally, what we would need is just to add an _edit_ link to each Forrest page that points to the url Lenya uses for editing. Currently this is done through filter XSL's (see the daisy plugin in the locationmap branch), but I think views may provide a better solution. It's on my todo list. Looking at the Doco document [1] I see that Lenya and Forrest are not directly interacting, as both talk to a common repository. The wiki is down at the moment. I'll come back to the rest of this mail later. Ross
Re: Questions about the release instructions
Following the developing discussion amongst you and having tried to do a few of the things you mentioned, I'm feeling slightly overwhelmed by the complexity of the task. So looking at our ambitious time frame I'd like to take up David on his offer I reckon it would be better that i do the process and that Ferdinand helps me or at least comes along for part of the ride. and suggest that he does the release and I try to follow, and understand, help where I can and update the documentation so that I can do it next time. -- Ferdinand Soethe
Re: svn commit: r189541 - /forrest/trunk/site-author/status.xml
Juan Jose Pablos wrote: [EMAIL PROTECTED] wrote: Author: crossley Date: Wed Jun 8 00:29:42 2005 New Revision: 189541 URL: http://svn.apache.org/viewcvs?rev=189541view=rev Log: Add missing @type attribute for one entry. sorry, I was testing jedit for editing status. Do you think that this attribute should be marked as required? yes, it is used in the projectInfo plugin. Ross
Re: cocoon protocols
David Crossley wrote: Tim Williams wrote: Ross Gardler wrote: According to my understanding as expressed above a cocoon:/ in the project sitemap will *not* search the root sitemap, a cocoon:// will. Of course, you have provided an example that indicates this is not the case despite the Cocoon docs agreeing with this. The hypothesised fallback behaviour would fit this case too. To have a definitive answer you will need to search the cocoon mail list archives and if necessary ask over there. I did search the Cocoon mailing list and it brought me some comfort in knowing that there are many folks confused by the cocoon protocols. :-) I reckon that it would be wise for someone to ask either cocoon-users or cocoon-dev about our issue. Can either Tim or Ross pose the correct question? I can't. I'll take it to the Cocoon user list soon, if Tim doesn't beat me to it. Also do you think that this affects our release? No, everything works just fine. It is just something Tim has uncovered because his method of learning is to read the code (now that is the kind of developer I like - he is even patching our docs as a result of his studies!) I hestitated to say this next comment, because it might be off track. Gianugo reported problems to cocoon-dev: Subject: cocoon:// protocol and map:mount Date: 2005-03-21 http://marc.theaimsgroup.com/?t=4064461 This may be relevant in that the bug referred to in that thread is a stack overflow, Tim has shown cocoon:/ actually goes to the root sitemap when it shouldn't. I can imagine it is possible to create a sitemap in which this would result in a stack overflow. But this is only guesswork right now, like David, I am hesitant to say the two things are connected. What is important to realise is that Forrest is *not* suffering from that bug. This stuff has been in place since the very early days of Forrest and we have not found a problem with it yet. It is potentially worrying though since we are using mounts and the cocoon: protocol extensively in Forrest, even more so with the plugin architecture. I think the course of action is: 1) get the official word from cocoon users about what behaviour should be found in Tim's example cases 2) get the official word as to why that behaviour doesn't happen (assuming my interpretation of the docs is correct) 3) if necessary go to the Cocoon dev list and ask if there is a likely connection between 2) and the bug in the above linked thread Tim, feel free to do this if you have the time/inclination. If not I'll get to it sometime after the 0.7 release. I've added a task in our issue tracker at http://issues.apache.org/jira/browse/FOR-529. Ross
[jira] Created: (FOR-528) Add version control to plugins
Add version control to plugins -- Key: FOR-528 URL: http://issues.apache.org/jira/browse/FOR-528 Project: Forrest Type: Improvement Versions: 0.7-dev Reporter: Ross Gardler Assigned to: Ross Gardler Priority: Blocker Fix For: 0.7-dev David Crossley wrote: Ross, are you able to explain what needs to happen with the plugins at release-time. I mean do they all need to have -0.7 appended to the names of the zip files? Blast I forgot that entirely (again!). Yes we need two zipped versions, a pluginname-0.7.zip and a pluginname-0.8-dev.zip The system will then download the correct version for the currently installed version of Forrest. This will allow us to have a separate release cycle for plugins, if we deploy from a 0.8-dev version of Forrest then we will have the 0.8-dev zip file. However, now I write that down I don't like it because there is no distinction between a 0.1 version of a plugin for Forrest 0.7 and a 1.0 version of a plugin for Forrest 1.0 (for example) How about I change it to put the plugins in a directory so we have: 0.7/plugingOne-0.1.zip 0.7/plugingTwo-0.2.zip 0.8-dev/pluginOne-0.2-dev.zip 0.8-dev/plugingTwo-0.2.zip We only allow *-dev plugins in the current *-dev branch of Forrest We can worry about the release process for plugins after this release (just get them out there for 0.7, we can blow the trumpet on subsequent upgrade releases) Do we need to add something to our RELEASE_BOTES.txt file? Yes, a section on plugins with a link to the plugins page, I'll add to project-info plugin Does someone need to tweak the build file? Yes, leave it with me, I'll implement the above with whatever modifications people think we need. Ross (for follow ups see http://marc.theaimsgroup.com/?l=forrest-devm=111821546807300w=2 -- 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: Questions about the release instructions
David Crossley wrote: - Set your Java version to be the lowest specified of our supported versions. Where is the definitive info on the supported versions? The FAQ says we need Java 1.4 or better. Does that mean it has to be 1.4.0 or can it be 1.4.x 1.4.0 Oooh, glad you asked that question. I was just going to use 1.4.1 Last time i did not use 1.3.0 rather 1.3.1 I think that we should test with 1.4 in its most current fix-version and update our requirements to reflect that. If we test against 1.4.0 we might find bugs that result from bugs in 1.4.0 and have been fixed in the more recent versions. And we might not find bugs that have been introduced with these fixes. So we are hurting people that do what you should be doing (update your java regularly to the latest fix version) to what end? -- Ferdinand Soethe
Re: old skins leather-dev and corium?
On Wed, 2005-06-08 at 16:51 +1000, David Crossley wrote: There are two skins of uncertain status: leather-dev and corium. Are they part of the Views now and we don't need them any more? They are not listed when we do 'forrest available-skins'. Actually leather-dev is the default skin for views. Trying to say that views interact with this skin to produce the xhtml. Right now the views are just exchanging the last step of the skining process (site2html.xsl). Views still depend on the leather-dev skin to produce the presentation model. We cannot delete leather-dev but I will clean it up a bit. ;-) As soon as more devs/committer start with views I hope we can come back to this topic. The question that needs to be resolved is how to provide a similar processing like the old fashion skins. -tab2menu.xsl -book2menu.xsl -document2html.xsl An idea of mine would be to base it on the common skin or start the work on the businessHelper plugin that should be do this processing and deliver the presentation model (pm). I would like to see the default skin that we will deliver with views with the name corium because it will be that what I thought corium would be. A skin that can be altered to e.g. a CSS-Zen garden skin within minutes. If they are not needed, then can we remove them, as i reckon they will confuse new users. Alternatively we could put a README.txt in that directory and hope that people read it. I understand that can confuse the user, we should make a README stating that corium and leather-dev are only connected to the development for views. Where leather-dev will be the producing factory for the pm of views and corium the default skin based on views (the minimalistic skin from Diwaker Gupta, should be renamed to corium). WDYT? salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
[jira] Created: (FOR-529) Validate our use of cocoon:// and cocoon://
Validate our use of cocoon:// and cocoon:// --- Key: FOR-529 URL: http://issues.apache.org/jira/browse/FOR-529 Project: Forrest Type: Task Reporter: Ross Gardler Priority: Minor Tim Williams has highlighted an inconsitency in our use of the cocoon:/ and cocoon:// protocols. At best this leads to confusion for new developers learning by reading the code, at worst it may trigger an existing bug in Cocoon (this has not been verified). We need to work with the Cocoon community to ensure our use of the cocoon protocol is correct. For a discussion of the problem see http://marc.theaimsgroup.com/?t=11180318082r=1w=2 -- 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: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
On Wed, 2005-06-08 at 09:21 +0100, Ross Gardler wrote: Nicola Ken Barozzi wrote: Gregor J. Rothfuss wrote: ... so initially, people could write documents in lenya, publish them, and then head over to forrest(bot?) to slurp all these pages in? My personal view is not to use the Forrestbot, but to mod_proxy/mod_cache a live Forrest instance that gets files from a published Lenya pubblication. In this way, publishing in Lenya is the only step needed to... publish :-) OK - as long as someone shows me how when the time comes. This would mean published docs in Lenya that are already *approved* for publication in the final docs would automatically appear. New published docs in lenya would need adding to the relevant site.xml for the real docs, this is the point at which we bring order to the chaos (the http://www.answers.com order to the http://www.wikipedia.org chaos) Yes, new docs have to be published before they are going into svn. I will have a look after I finished the last view how-to that is on my todo list. Anyway I hope we (as in lenya) can show an example pretty soon, that we get some momentum. The only thing is that there are so much do to and so limit time. ;-) Aditionally, what we would need is just to add an _edit_ link to each Forrest page that points to the url Lenya uses for editing. Currently this is done through filter XSL's (see the daisy plugin in the locationmap branch), but I think views may provide a better solution. It's on my todo list. :) Yeah, that is simply a contract that contains a link to daisy/lenya/anyOtherCms edit page. I will make an example as soon I have updated the locationmap branch on my harddrive and understood all the mails around the topic. ;-) Looking at the Doco document [1] I see that Lenya and Forrest are not directly interacting, as both talk to a common repository. The wiki is down at the moment. I'll come back to the rest of this mail later. Ross salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
Thorsten Scherler wrote: On Wed, 2005-06-08 at 09:21 +0100, Ross Gardler wrote: Nicola Ken Barozzi wrote: ... Aditionally, what we would need is just to add an _edit_ link to each Forrest page that points to the url Lenya uses for editing. Currently this is done through filter XSL's (see the daisy plugin in the locationmap branch), but I think views may provide a better solution. It's on my todo list. :) Yeah, that is simply a contract that contains a link to daisy/lenya/anyOtherCms edit page. I will make an example as soon I have updated the locationmap branch on my harddrive and understood all the mails around the topic. ;-) I'll do you a deal, if you create the contract with an example linking to the demo page Gregor created for us, I'll move it into the Locationmap branch and make it work with that the locationmap stuff. i.e. just hard code the URLs in the contract, I'll do what is necessary with locationmap. Ross
Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
On Wed, 2005-06-08 at 10:08 +0100, Ross Gardler wrote: Thorsten Scherler wrote: On Wed, 2005-06-08 at 09:21 +0100, Ross Gardler wrote: Nicola Ken Barozzi wrote: ... Aditionally, what we would need is just to add an _edit_ link to each Forrest page that points to the url Lenya uses for editing. Currently this is done through filter XSL's (see the daisy plugin in the locationmap branch), but I think views may provide a better solution. It's on my todo list. :) Yeah, that is simply a contract that contains a link to daisy/lenya/anyOtherCms edit page. I will make an example as soon I have updated the locationmap branch on my harddrive and understood all the mails around the topic. ;-) I'll do you a deal, if you create the contract with an example linking to the demo page Gregor created for us, I'll move it into the Locationmap branch and make it work with that the locationmap stuff. I would like to set up that branch to work by default with views if that is alright with you? i.e. just hard code the URLs in the contract, I'll do what is necessary with locationmap. No, there is no need to hardcode urls in the contracts. We can use the same mechanism we used in the feeder-contract (remember the example you brought up as enhancement of the view design). This way each contract can be based on a different location per view. ...done deal. ;-) Ross salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
Thorsten Scherler wrote: On Wed, 2005-06-08 at 10:08 +0100, Ross Gardler wrote: Thorsten Scherler wrote: ... :) Yeah, that is simply a contract that contains a link to daisy/lenya/anyOtherCms edit page. I will make an example as soon I have updated the locationmap branch on my harddrive and understood all the mails around the topic. ;-) I'll do you a deal, if you create the contract with an example linking to the demo page Gregor created for us, I'll move it into the Locationmap branch and make it work with that the locationmap stuff. I would like to set up that branch to work by default with views if that is alright with you? Yes, that is just fine. I intend to use views to its fullest there. i.e. just hard code the URLs in the contract, I'll do what is necessary with locationmap. No, there is no need to hardcode urls in the contracts. We can use the same mechanism we used in the feeder-contract (remember the example you brought up as enhancement of the view design). Yes, but the URL has to come from the locationmap. What I meant was you throw together a simple demo and I'll add the locationmap stuff. Of course, if you want to use this as an opportunity to get to grips with the locationmap I'll answer your questions instead of doing it. Ross
Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
On Wed, 2005-06-08 at 11:11 +0100, Ross Gardler wrote: Thorsten Scherler wrote: On Wed, 2005-06-08 at 10:08 +0100, Ross Gardler wrote: Thorsten Scherler wrote: ... :) Yeah, that is simply a contract that contains a link to daisy/lenya/anyOtherCms edit page. I will make an example as soon I have updated the locationmap branch on my harddrive and understood all the mails around the topic. ;-) I'll do you a deal, if you create the contract with an example linking to the demo page Gregor created for us, I'll move it into the Locationmap branch and make it work with that the locationmap stuff. I would like to set up that branch to work by default with views if that is alright with you? Yes, that is just fine. I intend to use views to its fullest there. :) ok +1 i.e. just hard code the URLs in the contract, I'll do what is necessary with locationmap. No, there is no need to hardcode urls in the contracts. We can use the same mechanism we used in the feeder-contract (remember the example you brought up as enhancement of the view design). Yes, but the URL has to come from the locationmap. What I meant was you throw together a simple demo and I'll add the locationmap stuff. Of course, if you want to use this as an opportunity to get to grips with the locationmap I'll answer your questions instead of doing it. I will give it a go after the how-to. I need to get into that stuff to help lenya, forrest and the businessHelper plugin. ;-) ...and do not worry, I know your eMail address. ;-) lol salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: [SUMMARY] Re: [PROPOSAL] A CMS for our Docs
David Crossley wrote: Nicola Ken Barozzi wrote: David Crossley wrote: Ross Gardler wrote: ... Does this sound OK? It sounds brilliant. Indeed! The part that i like most is that each project is focussing on their own tools, we are not duplicating, and we are collaborating. David, it seems Ross cracked open the coconut [1] and we now have opensource nirvana. Cool beans! :-) [1] Since sayings are so different from place to place, I am inventing my own, so all will be equally disoriented ;-) Yes, i do get your drift (i.e. know what you mean). Hey Ross, do coconut milk and Whiskey mix? If so then i'll buy you one or two at ApacheCon. If not, then still, name your poison. I'm afraid I'm a bit of a snob [1] when it comes to whiskey - nothing but a splash of water in the best single malt available is all that will do. However, coconut water and rum, now that works well, is much cheaper, and I don't have to be snobbish about it ;-) (incidentally, Nicola, I'm afraid I heard that saying in Trinidad - it refers to being totally parched in the sun with nothing to drink but Coconut Water, which can only be found in the green nuts, which are 40 feet in the air, still on the palm trees.) Ross [1] For the non-English speakers you may need this, snob is not a common word, at least in the UK, anymore: http://dictionary.reference.com/search?q=snob
[jira] Commented: (FOR-527) The project.issues-rss-url in forrest.properties need to refer to apache.org
[ http://issues.apache.org/jira/browse/FOR-527?page=comments#action_12313031 ] Ross Gardler commented on FOR-527: -- Actually I noted this when making the previous comment: http://issues.apache.org/jira/secure/IssueNavigator.jspa?view=rsspid=1231fixfor=12310031resolutionIds=-1sorter/field=prioritysorter/order=DESCtempMax=25reset=truedecorator=none This came from the XML link on the Browse 0.7-dev page The project.issues-rss-url in forrest.properties need to refer to apache.org Key: FOR-527 URL: http://issues.apache.org/jira/browse/FOR-527 Project: Forrest Type: Bug Versions: 0.7-dev Reporter: David Crossley Fix For: 0.7-dev Following the move of Jira to apache.org Jira, our project.issues-rss-url needs adjustment. I have not yet been able to find the new URL. -- 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: (FOR-531) Searchbox floats to top in Moz browsers
Searchbox floats to top in Moz browsers - Key: FOR-531 URL: http://issues.apache.org/jira/browse/FOR-531 Project: Forrest Type: Bug Components: Skins (general issues) Versions: 0.7-dev Environment: Netscape 7.x and Firefox 1.0.4 on WinXP and Linux Reporter: Addison Berry Priority: Minor When first going to a site created with apache forrest the searchbox is floating at the top of the page. Reloading the page or going to another page corrects it and it goes to its normal place and stays there for the rest of the browser session. Close and reopen the browser and it is floating again. Observed at Apache Forrest and Apache Lenya on the web as well as a newly seeded local site. -- 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
Couldn't attach screenshot to JIRA
I just opened a new issue and had to load the screenshot up by attaching a gif file (using attach file). When I tried to use the attach screenshot option, it seemed like it was working (paste screenshot, add comment, click attach) but after I clicked attach and the page reloaded, there was no screenshot or comment for the issue. Tried twice before I just decided to attach file. Addi
[jira] Updated: (FOR-531) Searchbox floats to top in Moz browsers
[ http://issues.apache.org/jira/browse/FOR-531?page=all ] Addison Berry updated FOR-531: -- Attachment: searchbox_float.gif Attached screenshot of what I'm seeing. (attached as gif file because I can't attach a screenshot for some reason.) Searchbox floats to top in Moz browsers - Key: FOR-531 URL: http://issues.apache.org/jira/browse/FOR-531 Project: Forrest Type: Bug Components: Skins (general issues) Versions: 0.7-dev Environment: Netscape 7.x and Firefox 1.0.4 on WinXP and Linux Reporter: Addison Berry Priority: Minor Attachments: searchbox_float.gif When first going to a site created with apache forrest the searchbox is floating at the top of the page. Reloading the page or going to another page corrects it and it goes to its normal place and stays there for the rest of the browser session. Close and reopen the browser and it is floating again. Observed at Apache Forrest and Apache Lenya on the web as well as a newly seeded local site. -- 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: Questions about the release instructions
Thanks for fixing some of the docs already, David. Some questions remaining: - Set your Java version to be the lowest specified of our supported versions. e.g. J2SDK 1.4.0 See my ealier posting on this. - Run 'build release-dist' to generate the distributions on a UNIX machine. - Two archives are created: apache-forrest-X.Y.tar.gz apache-forrest-X.Y.zip - Repeat that on a Windows machine. - Use the .tar.gz from the UNIX machine and .zip from the Windows machine. - In that way, SVN will ensure correct line-endings on all text files. This doesn't look right but I may be wrong: - Run 'build release-dist' to generate the distributions on a UNIX machine. An archive apache-forrest-X.Y.tar.gz is created. - Run 'build release-dist' to generate the distributions on a Windows machine. An archive apache-forrest-X.Y.zip is created. - Use the .tar.gz from the UNIX machine and .zip from the Windows machine. - In that way, SVN will ensure correct line-endings on all text files. Use for what? Should it be something like Use tar.gz for installing the test release on a unix machine and zip for installing it in Windows machines. - In that way, SVN will ensure correct line-endings on all text files. What has svn to do with it at that point? - Create a maintenance branch in SVN with svn copy -m Create the x.y release branch from r# \ https://svn.apache.org/repos/asf/forrest/trunk \ https://svn.apache.org/repos/asf/forrest/branches/forrest_xy_branch where 'xy' is a compact form of the version (e.g. 04, 041, 05). See http://svn.apache.org/repos/asf/forrest/branches/ So is r## to be replaced by the current dev-release number (0.7-dev). To be continued once I've read some more :-) -- Ferdinand Soethe
draft proposal
Hello! Ross! Ive tried to locate the Eclipse plug-in, that you mentioned, the alpha one. But I wasnt able to find it in http links download. Tonight I will checkout forest from trunk cause it its expensive to do that in the day time. But even without it here is some kind of my proposition draft. Description of the problem Forest is a publication framework, powerful and useful. But let us take a look at what a new person should handle to start a productive work with Forest. We can say that besides content enrichment, user should manage configuration files, skins (in future views), site.xml file. All the management, mentioned above, requires edition of text based files, what might be confusing for a new user. So, to my point of view, there is a clear need for a editing front-end to Forest publication framework. Another point is that Forest can be used to construct useful content for third party software. E.g. Forest can be used to generate help contents for Eclipse Rich Client Application. Such feature will help to promote use of Forest in Eclipse community. Proposed solution. Proposition is to create an editing front-end in a form of Eclipse plug-in, containing forms and wizards, that can help edit configuration files, site.xml file and application of skins (or views). As soon as Eclipse can help to promote Forest, let Forest help Eclipse RCP developers. Proposition is implement following: 1) extend Forest plug-in (or create another one) to let it generate Help based on contents from XML. 2) Some part of XML contents can be marked to be used as Eclipse Cheat Sheets, that in form of site should be rendered as HOW-TOs. Benefits of the solution to the Apache community With implemented tools, mentioned above, new and experienced Forest users can have more convenient access to configuration files and such, using Eclipse. And Eclipse users can benefit from Forest framework. This suggestion will result in growth of popularity for both Apache Forest and Eclipse. This is the main benefit, to my point of view. From technical point of view, the deliverables are: 1) Configuration editing front-end with views, wizards and help 2) Help generation plug-in, based on Forest. 3) Cheat sheets extension for help plug-in mentioned in 2) Approach: Milestones in delivery 1) Clear and definite requirements to editing front-end (Editing plug-in). 2) Design of specified requirements. 3) Specification of requirements and design elements that will be included in basic level of architecture. I believe, it should be a functionality that allows to create some sample sites AND Eclipse RCP Help site. 4) Implementation of basic level of architecture with corresponding Accuracy, Failure and Stress test cases. 5) Reviewed requirements and design. 6) Implementation of the rest of requirements according to review design. 7) Requirements and design for Help generation plug-in.* 8) Implementation of sample help generation site* 9) Implementation of help generation plug-in and tests. (Cheat sheets included)* 10) User guide creation based on javadoc, requirements docs and design docs *Tasks might be started as task 4 is finished. Expected time line for delivery 06.28 Task 1 delivery. Two weeks will be needed to analyze current Apache Forest situation and features, because it was older version, that Ive worked with. 07.05 Task 2 and 3 delivery. With some bit of task 3 as an illustration that Design will work. Next are hard to predict 07.25 Task 4 delivery 07.28 Task 5 08.20 Everything should be ready for final fixes 08.30 Help delivery. Description of relevant students skills Im finishing Byelorussian State University this year. (But yet Im still a). Ive started my IT specialist career 7 years ago, when I was 15. Ive worked with FoxPro, Delphi, C++ Builder in Mogilev, Minsk and Moscow. For last three years Im in love with Java. In java Ive worked with BEA Weblogic, Hibernate, Struts. Last Autumn Ive quit EPAM (www.epam.com) CMI level 4 company, to start a development initiative with my friends called BEKAR. Currently we are developing a software using Eclipse, Hibernate and some native components. To Apache Forest I relate as end user. I did not have time to help to develop it, but if it is sponsored I eagerly would, because I really enjoy the idea. My Brain Bench java results are here http://www.brainbench.com/xml/bb/transcript/public/transcript_testdetails.xml?back=1pid=4754989testid=5929215 Thank you! Good Luck!
Re: [views] Survival guide and setup
On Mon, 2005-06-06 at 20:15 +0200, Ferdinand Soethe wrote:
Comments from trying it:
Thorsten Scherler wrote:
I will write a howto on that I promise! For now try the following
survival guide:
*setup*
1) The first step is to build the view and the viewHelper plugins (that
will be easier in the future, we promise)
cd {forrest-trunk}
svn up
cd whiteboard/plugins/org.apache.forrest.plugin.internal.view/
ant local-deploy
cd ../org.apache.forrest.plugin.output.viewHelper.xhtml/
ant local-deploy
2) Then seed an new project:
cd ~/src/newSeed
forrest seed
3) Then add the plugins to the forrest.properties:
project.required.plugins=org.apache.forrest.plugin.output.viewHelper.xhtml,org.apache.forrest.plugin.internal.view
4) Change the project skin to leather-dev (we exchanging only
site2xhtml.xsl of that skin by the plugins and some contracts are based
on e.g. document2html.xsl output of leather-dev)
project.skin=leather-dev
5) prepare default.fv directory (project.conf-dir)
mkdir src/documentation/conf
6) Now you have finished the preparation and the setup to finally try
forrest run
Wow. Works like a charm. Had it running in no time. Fun!
:) It is now in a how-to.
Note: When developing styles with views 'forrest run' is the quickest
way. You will see you do not have to build your project to see the
changes on your pages when working with *.fv.
*changing views* - *.fv
For changing the view of a page, you can start by copying
http://svn.apache.org/viewcvs.cgi/*checkout*/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/resources/views/default.fv
to e.g. index.fv. This view *has to* be in the same dir as the document
(e.g. index.xml). This is defined in forrest.properties by
#project.xdocs-dir=${project.content-dir}/content/xdocs
To change the default view of your project you have to create a
default.fv (copy above mentioned) in the dir defined in the
forrest.properties by
#project.conf-dir=${project.content-dir}/conf
I now assume you have the following files new added to the seed (if you
did not change any default props):
src/documentation/conf/default.fv
src/documentation/content/xdocs/index.fv
Now the rule for the view matching is
1.) page specific view (e.g. index.fv)
2.) default view (src/documentation/conf/default.fv)
How about a per directory view?
It should be possible but not implemented. Patches welcome. ;-)
Lets try this rule by changing in index.fv:
!--forrest:contract name=grouplogo/--
save and test:
http://localhost:/index.html
You will find that the grouplogo will not be rendered. Now let test how
the other pages look like:
http://localhost:/samples/sample.html
You see again the grouplogo. To change it in all pages we have to edit
src/documentation/conf/default.fv.
This doesn't work with the current skin because their is no group
logo. Commenting out
Ok, sorry thanks for the headup I will try better in the forrest
config-DSL how-to that I will start writing after this mail.
forrest:hook name=export-link
forrest:contract name=txt-link/
forrest:contract name=pdf-link/
/forrest:hook
works just as well.
Now all pages do not have the grouplogo. For further information see
e.g.
http://marc.theaimsgroup.com/?l=forrest-devm=111800598325769w=2
See above.
*CSS support*
Note: Right now we still have the css generation out of contracts but
that will be history as soon we can provide a default.css that is doing
this job. You will find in samples/sample.html (as indicator):
link href=../skin/contracts-samples/sample.css rel=stylesheet
type=text/css /
Now to add your own css to the view:
http://marc.theaimsgroup.com/?t=11136081541r=1w=2n=7
Basically you have to add
forrest:css url=someCss.css/
to the view to add your own css-stylesheet.
This tag has to be direct son from forrest:view!
In the resource.xmap of the plugins we defined a matching rule for
custom css:
map:when test={project:skins-dir}{path}/{name}.css
That means e.g.
forrest:css url=prosimii-screen-alt.css/
would expect (with default values)
src/documentation/skins
|-- css
`-- prosimii-screen-alt.css
For programming contracts see my recent thread and the upcoming how-to
(where you can find a lot of what you just read) ;-).
You have lost me on the CSS. How is this done, what is each step
about. Would love to understand that.
Ok, I will let you know when I wrote it down in a how-to.
Thanks for explaining.
Thx for the feedback. :)
Ferdinand
--
Ferdinand Soethe
salu2
--
thorsten
Together we stand, divided we fall!
Hey you (Pink Floyd)
[jira] Work started: (FOR-528) Add version control to plugins
[ http://issues.apache.org/jira/browse/FOR-528?page=all ] Work on FOR-528 started by Ross Gardler Add version control to plugins -- Key: FOR-528 URL: http://issues.apache.org/jira/browse/FOR-528 Project: Forrest Type: Improvement Versions: 0.7-dev Reporter: Ross Gardler Assignee: Ross Gardler Priority: Blocker Fix For: 0.7-dev David Crossley wrote: Ross, are you able to explain what needs to happen with the plugins at release-time. I mean do they all need to have -0.7 appended to the names of the zip files? Blast I forgot that entirely (again!). Yes we need two zipped versions, a pluginname-0.7.zip and a pluginname-0.8-dev.zip The system will then download the correct version for the currently installed version of Forrest. This will allow us to have a separate release cycle for plugins, if we deploy from a 0.8-dev version of Forrest then we will have the 0.8-dev zip file. However, now I write that down I don't like it because there is no distinction between a 0.1 version of a plugin for Forrest 0.7 and a 1.0 version of a plugin for Forrest 1.0 (for example) How about I change it to put the plugins in a directory so we have: 0.7/plugingOne-0.1.zip 0.7/plugingTwo-0.2.zip 0.8-dev/pluginOne-0.2-dev.zip 0.8-dev/plugingTwo-0.2.zip We only allow *-dev plugins in the current *-dev branch of Forrest We can worry about the release process for plugins after this release (just get them out there for 0.7, we can blow the trumpet on subsequent upgrade releases) Do we need to add something to our RELEASE_BOTES.txt file? Yes, a section on plugins with a link to the plugins page, I'll add to project-info plugin Does someone need to tweak the build file? Yes, leave it with me, I'll implement the above with whatever modifications people think we need. Ross (for follow ups see http://marc.theaimsgroup.com/?l=forrest-devm=111821546807300w=2 -- 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: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
Nicola Ken Barozzi wrote: (cc'd to Lenya Dev for their comments as well - please reply-all) ... Looking at the Doco document [1] I see that Lenya and Forrest are not directly interacting, as both talk to a common repository. Right now, what we have is: --- committers ---. . Non-Committers --- | | | | +-++---++--+ | Forrest |---| Lenya |--|Lenya Repo| +-++---++--+ (I've simplified by ignoring other repository types, but we should remember Forrest can now integrate content from multiple repositories, for example, Tim has the Locationmap working with a slide repo and you know that we have Daisy too) This architecture does not allow for committers to write docs with their preferred tools via SVN, as has been requested. Nor does it keep the published artifacts in SVN as is desired on Apache projects. So I see the target architecture like this: committers . . Non-Committers --- | | | | +-++-++---++--+ | Forrest |---| SVN |---| Lenya |---|Lenya Repo| +-++-++---++--+ . /|\ | /|\ |___| | ++ | Committers | | Tools | ++ So non-committers edit freely in the Lenya repo but cannot publish within Lenya. When an edit is reviewed and published by a committer, that change is propagated to SVN. Committers can use whatever tool they prefer, working directly with SVN or with Lenya. In this model there is the potential for conflict between edits in the Lenya Repo that have not yet been published and edits by committers working directly with SVN. In my view this is no more of a problem than the potential for conflicts between in progress edits on individual checked out copies of SVN, or at least if we stay on top of publishing changes to Lenya this should be the case. What do others think about this? What do you think about this architecture, is it really needed? I'm not sure it's *that* different from asking Lenya to get the docs for us, as it's a simple URL request. Basically, Lenya would be doing what the SLIDE+LENYA combo does in the graphic, thus removing the need for DASL that only Slide at Apache has, making us use Subversion. I agree. The above is very similar to the original proposal minus the mail workflow) What remains to do are diffs. The above gives us diffs of published documents but Lenya does not publish good diffs of edits of its own repository. However, the Lenya community are addressing this (I have a Summer of Code applicant who has expressed interest in this aspect and a couple of Lenya devs have agreed to co-mentor). I'm not sure that the mail workflow is something we really need ATM. IMHO just adding editors that cannot publish, along with diffs, is something that gives us enough control. I agree. The mail workflow is a nice have. It would be wonderful to be able to publish simple changes by replying to a mail as is proposed in [1]. But we can manage with the diffs and a link to an URL to publish the changes, and another to reject the changes. Ross [1] http://wiki.apache.org/cocoon/Doco
[jira] Created: (FOR-534) Skin sample donation
Skin sample donation Key: FOR-534 URL: http://issues.apache.org/jira/browse/FOR-534 Project: Forrest Type: Improvement Components: Other Versions: 0.6 Reporter: Torsten Stolpmann Priority: Minor As discussed on dev@forrest.apache.org here are the skin sources to our forrest website. Please refer to the Notes.txt contained inside the attachment for further comments. Feedback welcome. -- 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: (FOR-534) Skin sample donation
[ http://issues.apache.org/jira/browse/FOR-534?page=all ] Torsten Stolpmann updated FOR-534: -- Attachment: verit-forrest-sample.zip Skin sample donation Key: FOR-534 URL: http://issues.apache.org/jira/browse/FOR-534 Project: Forrest Type: Improvement Components: Other Versions: 0.6 Reporter: Torsten Stolpmann Priority: Minor Attachments: verit-forrest-sample.zip As discussed on dev@forrest.apache.org here are the skin sources to our forrest website. Please refer to the Notes.txt contained inside the attachment for further comments. Feedback welcome. -- 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: [RT] Accepting and managing Skin Packages (was Re: Forrest Example Sites)
Ross Gardler wrote: Torsten Stolpmann wrote: As Claudia already pointed out, most work done on pelt was rather destructive (disabling/removing features we didn't need/like/got in the way) than constructive. I've often wanted to disable certain features in our skins, but never found the time to do it. The diffs between your work and pelt will clearly indicate where the code is that should be disabled for various features. With the use of some extra skin config and xsl:if elements those with a strong enough itch should be able to add at least some of your changes into pelt. So in conclusion: I don't see our work as a new 'skin'. It is too narrow and specialised for that to be in it's current state. Then again it might serve as a showcase on *what* visuals can be achieved and especially *how* they may be achieved. I agree with your conclusion. If you are still willing please add your skin to an issue, if possible add a few notes about the major changes you made (in terms of functionality, i.e. added an image to tabs, people can look at the code to see how) Added to Jira as FOR-504. Sorry for the delay. I hope the comments inside are sufficient. If not - just ask. Finally, may I take this opportunity to thank you and your company for your offer to donate your excellent work on this skin, it is very much appreciated by the community. Glad to be of help. Ross Torsten
[jira] Created: (FOR-532) Auto Generate plugins.xml entry
Auto Generate plugins.xml entry --- Key: FOR-532 URL: http://issues.apache.org/jira/browse/FOR-532 Project: Forrest Type: Improvement Reporter: Ross Gardler -- 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: old skins leather-dev and corium?
Thorsten Scherler wrote: David Crossley wrote: There are two skins of uncertain status: leather-dev and corium. Are they part of the Views now and we don't need them any more? They are not listed when we do 'forrest available-skins'. Actually leather-dev is the default skin for views. Trying to say that views interact with this skin to produce the xhtml. Right now the views are just exchanging the last step of the skining process (site2html.xsl). Views still depend on the leather-dev skin to produce the presentation model. We cannot delete leather-dev but I will clean it up a bit. ;-) As soon as more devs/committer start with views I hope we can come back to this topic. The question that needs to be resolved is how to provide a similar processing like the old fashion skins. -tab2menu.xsl -book2menu.xsl -document2html.xsl An idea of mine would be to base it on the common skin or start the work on the businessHelper plugin that should be do this processing and deliver the presentation model (pm). I would like to see the default skin that we will deliver with views with the name corium because it will be that what I thought corium would be. A skin that can be altered to e.g. a CSS-Zen garden skin within minutes. If they are not needed, then can we remove them, as i reckon they will confuse new users. Alternatively we could put a README.txt in that directory and hope that people read it. I understand that can confuse the user, we should make a README stating that corium and leather-dev are only connected to the development for views. Where leather-dev will be the producing factory for the pm of views and corium the default skin based on views (the minimalistic skin from Diwaker Gupta, should be renamed to corium). WDYT? Thanks for taking the time to explain that. Yes, i added the readme. Should corium be called corium-dev? --David
locationmapped resources
I've got resources in resources.xmap looking at locationmap now. I haven't done it for any non-image resource though.Should the following matches be resolvable through locationmaps too? I can't off the top of my head think of any reason why not but thought it important enough to query. map:match pattern=**skin/**.js map:match pattern=**.js map:match pattern=**skin/**.css map:match pattern=**.css map:match pattern=skin/images**/*c-*-*-*-1*-2*-3*.png btw, what the heck is that last one all about anyway? --tim
Re: [jira] Commented: (FOR-506) Do not hard-code site-visible message strings in skin files
On Wed, 2005-01-06 at 12:02 +0200, Juan Jose Pablos wrote:
Pedro I. Sanchez wrote:
Anyway, first I verified that setting value=es_ES in
main/webapp/sitemap.xmap indeed works. It brings the Spanish strings
from the right catalogue. I also verified that value=${env.LANG} does
*not* work.
are you sure that the $LANG property is set on your system?
if not do an export LANG=es_ES
do an echo $LANG before running forrest site to verify that the change
has been made.
The string $(env.LANG} works well inside main/forrest.build.xml. It was
the default before you made changes to the trunk. But the same string is
ignored when you use it inside webapp/sitemap.xmap (skin labels are
looked up in the English dictionary, even if LANG=es_ES).
1) First change
-#project.i18n=true
+project.i18n=true
+project.language=es_ES
And this alone works just well. The site is generated under
build/site/es_ES but with English labels. The next step is
required to get the translations in place.
The i18naction does not know anything about project.language that is why
it does not translate
That's what I was trying to figure out in my 'second change'.
2) Second change: Reflecting these changes in the sitemap
Unfortunately these gives me a null pointer and dies :( But there's tons
of {project:} strings used everywhere in the site map! So, what's
missing to make my newly created language property to work?
forrest.build.xml likes it but sitemap.xmap doesn't.
Well you change the new stuff about a skin i18n aware. There is more
stuff that needs to change. Still, I think that the main issue that you
have is that forrest does not get you env.LANG property.
forrest.build.xml does. sitemap.xmap doesn't.
I have change that so it uses {user.language} instead. try to svn up
and report if that is working for you.
I don't believe what you did is right, sorry if I misunderstand :|
You replaced my 'project.language' with 'user.language' but you are not
defining 'user.language' in forrest.build.xml. So it does nothing when I
use it in my site's 'forrest.properties'.
So, let me rephrase my understanding of this issue so far. Before you
made changes to trunk this was the behaviour:
1. Forrest seed; forrest would generate the static site in English,
regardless of your LANG env.
2. Setting project.i18n=true in forrest.properties and running forrest
again would generate your site in build/site/xx, where xx is determined
by the LANG env. BUT, the generated static site is still all in English;
no look up into the language-specific catalogues ever takes place.
With your changes to the trunk this is the current behaviour:
1. As before.
2. Setting project.i18n=true in forrest.properties and running forrest
again would generate your static site in build/site/en, regardless of
your LANG env. This is not the expected behaviour. And the site is
generated in English as before, no changes here.
My goal for a static site is to be able to issue the command
$ LANG=es_ES forrest
and get two things:
a) My site is built under build/site/es. This was OK before your
changes. It's not the case anymore.
b) Get the generated static site with Spanish skin labels. This was not
happening before and it's not happening now. The reason? We still have
the line
map:parameter name=locale value={request:locale}/
in sitemap.xmap which makes the translation unaware of the LANG setting.
Replacing it with
map:parameter name=locale value=${env.LANG}/
doesn't work. Replacing it with
map:parameter name=locale value={project.language}/
gives a NULL pointer somewhere.
I have some ideas on the i18n behaviour I'd like to see when generating
a static site which I'll share in a different e-mail.
Cheers,
--
Pedro
sitemap ?issues?.. maybe..
I apologize up front for being a pest while you guys are prepping for the release but... I started my queries into sitemaps with the cocoon:/ cocoon:// protocols but now I'm starting to wonder whether we have other sitemap related issues too. (Not issues in the sense of bugs, but issues in the sense of overly verbose code). Currently, in most, but not all of the subsitemaps there are duplicate transformer, generator, serializer declarations. Because the parent sitemap components are available to the subsitemap components I don't get why their sprinkled so liberally across subsitemaps. I think trimming the fat from subsitemaps would at least make the subsitemaps more readable. I don't immediately see as what the performance impacts would be because I don't know if component instances are created on demand or on startup. If it's the former, then the cost of instance creation vs. the costs of the parent lookup seem like they would at least offset one another. Anyone know why this is the way it is? Since the duplication is consistent it does make me question whether I've missed something but preliminary testing has not uncovered anything -- of course my current testing wouldn't uncover any performance issues if that happens to be the rationale. Is this just standard in Cocoon-based apps? I've added some of the basis for my understanding below. Thanks, --tim http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html Sitemap components (generators, transformers, etc.) in a sitemap are accessible from a sub-sitemap by their names. This is due to the fact that each sitemap has its own SitemapComponentManager and they are arranged in the same hierarchical structure as the sitemaps are and thus knows which are their parent SitemapComponentManager and can ask it for a SitemapComponent it doesn't know about. j.o.a.c.components\CocoonComponentManager.lookup() forrest.xmap (among others) An example can be seen by ripping out the entire map:transformers section from forrest.xmap. build cleanly; forrest run and all is well.
[jira] Closed: (FOR-527) The project.issues-rss-url in forrest.properties need to refer to apache.org
[ http://issues.apache.org/jira/browse/FOR-527?page=all ] David Crossley closed FOR-527: -- The project.issues-rss-url in forrest.properties need to refer to apache.org Key: FOR-527 URL: http://issues.apache.org/jira/browse/FOR-527 Project: Forrest Type: Bug Versions: 0.7-dev Reporter: David Crossley Fix For: 0.7-dev Following the move of Jira to apache.org Jira, our project.issues-rss-url needs adjustment. I have not yet been able to find the new URL. -- 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: sitemap ?issues?.. maybe..
Tim Williams wrote: I apologize up front for being a pest while you guys are prepping for the release but... No worries. Development continues on. You are not being a pest, far from it. Thanks anyway for being so considerate. I started my queries into sitemaps with the cocoon:/ cocoon:// protocols but now I'm starting to wonder whether we have other sitemap related issues too. (Not issues in the sense of bugs, but issues in the sense of overly verbose code). Currently, in most, but not all of the subsitemaps there are duplicate transformer, generator, serializer declarations. Because the parent sitemap components are available to the subsitemap components I don't get why their sprinkled so liberally across subsitemaps. I think trimming the fat from subsitemaps would at least make the subsitemaps more readable. I don't immediately see as what the performance impacts would be because I don't know if component instances are created on demand or on startup. If it's the former, then the cost of instance creation vs. the costs of the parent lookup seem like they would at least offset one another. Anyone know why this is the way it is? Since the duplication is consistent it does make me question whether I've missed something but preliminary testing has not uncovered anything -- of course my current testing wouldn't uncover any performance issues if that happens to be the rationale. Is this just standard in Cocoon-based apps? My guess is that it is just that we have not gone back and cleaned up the sitemaps code. The old issue with Opensource projects not being good at consolidation. Thanks for raising this issue. It is important that we do clean them up, if only to prevent confusion. Whether that happens before release or not, i don't know. If someone could do it quickly, then that would be excellent. Anyway, lets hope that someone else can confirm that. --David I've added some of the basis for my understanding below. Thanks, --tim http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html Sitemap components (generators, transformers, etc.) in a sitemap are accessible from a sub-sitemap by their names. This is due to the fact that each sitemap has its own SitemapComponentManager and they are arranged in the same hierarchical structure as the sitemaps are and thus knows which are their parent SitemapComponentManager and can ask it for a SitemapComponent it doesn't know about. j.o.a.c.components\CocoonComponentManager.lookup() forrest.xmap (among others) An example can be seen by ripping out the entire map:transformers section from forrest.xmap. build cleanly; forrest run and all is well.
