Differents between 'forrest' and 'forrest run'
Hello devs, trying to deploy the view and leather plugin I found a weird thing happening: Doing 'forrest run' brings the site rendered by the plugins, but doing 'forrest' will use the normal skin. How come? How can I fix that? Any ideas? TIA salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: Differents between 'forrest' and 'forrest run'
Thorsten Scherler wrote: Hello devs, trying to deploy the view and leather plugin I found a weird thing happening: Doing 'forrest run' brings the site rendered by the plugins, but doing 'forrest' will use the normal skin. How come? How can I fix that? Any ideas? What do i need to do to replicate the issue here? Do i just add to those plugins to forrest.properties project.required.plugins and change project.skin? --David
Re: Differents between 'forrest' and 'forrest run'
On Mon, 2005-04-04 at 19:42 +1000, David Crossley wrote:
Thorsten Scherler wrote:
Hello devs,
trying to deploy the view and leather plugin I found a weird thing
happening:
Doing 'forrest run' brings the site rendered by the plugins, but doing
'forrest' will use the normal skin.
How come? How can I fix that?
Any ideas?
What do i need to do to replicate the issue here?
Do i just add to those plugins to forrest.properties
project.required.plugins and change project.skin?
project.skin - should get ignored by the plugins! I am still using
skinit pipes but they can now come from pelt.
project.required.plugins- orgleather, org...view, org...
Just do
1) svn up in {forrest}/plugins
2) cd org...leather; ant local-deploy
3) cd org...view; ant local-deploy
4) in e.g. org...view 'forrest' and then 'forrest run'
You will see the plugin get rendered by 'forrest' with the pelt skin in
build/site. If you now turn to 'forrest run' instance you find a
complete different skin.
Now I just did a 'forrest' on a fresh seed where I add both plugins
(like you stated) and it is working just fine (static/dynamic show the
same). It seems only to be a problem in the plugin which is a bummer
because I cannot deploy them. :(
Cheers for your support.
:)
--David
salu2
--
thorsten
Together we stand, divided we fall!
Hey you (Pink Floyd)
Re: Differents between 'forrest' and 'forrest run'
Thorsten Scherler wrote:
David Crossley wrote:
Thorsten Scherler wrote:
Hello devs,
trying to deploy the view and leather plugin I found a weird thing
happening:
Doing 'forrest run' brings the site rendered by the plugins, but doing
'forrest' will use the normal skin.
How come? How can I fix that?
Any ideas?
What do i need to do to replicate the issue here?
Do i just add to those plugins to forrest.properties
project.required.plugins and change project.skin?
project.skin - should get ignored by the plugins! I am still using
skinit pipes but they can now come from pelt.
project.required.plugins- orgleather, org...view, org...
Just do
1) svn up in {forrest}/plugins
2) cd org...leather; ant local-deploy
3) cd org...view; ant local-deploy
4) in e.g. org...view 'forrest' and then 'forrest run'
You will see the plugin get rendered by 'forrest' with the pelt skin in
build/site. If you now turn to 'forrest run' instance you find a
complete different skin.
I get different behaviour. I see the same skins in both.
It looks like the pelt skin.
Now I just did a 'forrest' on a fresh seed where I add both plugins
(like you stated) and it is working just fine (static/dynamic show the
same). It seems only to be a problem in the plugin which is a bummer
because I cannot deploy them. :(
It breaks for me in both methods ...
---
/svn/asf/forrest/build/plugins/org.apache.forrest.plugin.view/src/documentation/default.fv
(No such file or directory
---
Perhaps you have some un-committed files.
--David
Re: Differents between 'forrest' and 'forrest run'
On Mon, 2005-04-04 at 20:41 +1000, David Crossley wrote: You will see the plugin get rendered by 'forrest' with the pelt skin in build/site. If you now turn to 'forrest run' instance you find a complete different skin. I get different behaviour. I see the same skins in both. It looks like the pelt skin. ...because you have not defined a view. Now I just did a 'forrest' on a fresh seed where I add both plugins (like you stated) and it is working just fine (static/dynamic show the same). It seems only to be a problem in the plugin which is a bummer because I cannot deploy them. :( It breaks for me in both methods ... --- /svn/asf/forrest/build/plugins/org.apache.forrest.plugin.view/src/documentation/default.fv (No such file or directory --- Perhaps you have some un-committed files. No, actually this default.fv is the last fallback. I forget to copy it over from the old views. I have views defined in my projects that is why I have not seen this error. Cheers for spotting it, I just checked it in. salu2 --David -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: Differents between 'forrest' and 'forrest run'
On Mon, 2005-04-04 at 21:02 +1000, David Crossley wrote: Thorsten Scherler wrote: David Crossley wrote: You will see the plugin get rendered by 'forrest' with the pelt skin in build/site. If you now turn to 'forrest run' instance you find a complete different skin. I get different behaviour. I see the same skins in both. It looks like the pelt skin. ...because you have not defined a view. I got error messages about plugins during the startup of both 'forrest' and 'forrest run'. I did not get these error messages from the forrest seed site below. That is what I mean. I now as well get the pelt skin and not the leather-plugin. Now I just did a 'forrest' on a fresh seed where I add both plugins (like you stated) and it is working just fine (static/dynamic show the same). It seems only to be a problem in the plugin which is a bummer because I cannot deploy them. :( It breaks for me in both methods ... --- /svn/asf/forrest/build/plugins/org.apache.forrest.plugin.view/src/documentation/default.fv (No such file or directory --- Perhaps you have some un-committed files. No, actually this default.fv is the last fallback. I forget to copy it over from the old views. I have views defined in my projects that is why I have not seen this error. Cheers for spotting it, I just checked it in. Okay now i see the default view in my forrest seed site doing both 'forrest' and 'forrest run'. Yeah now you can copy this default.fv to your xdocs dir and rename it to the file that should have a new style (view). e.g. index.xml (index.fv) Anyway it would be interesting to know why it is working for a seed but not for the plugins. I have to give now a course, will have a look tonight. cheers for testing it out. :) --David salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: problem with docs at forrest.apache.org/docs/dev/
David Crossley wrote: David Crossley wrote: David Crossley wrote: David Crossley wrote: Dave Brondsema wrote: /docs/dev/ nested below /docs/ seems weird. I think it would be better to host the current stable release at a url like: /docs/0.7/. This would also permit us to keep documentation for all old releases (although we would probably want warnings on them if they are too old). 0.6 docs had to be kept at /docs/ because they didn't have a split docs/site structure so I kept it as-is. I had been thinking we'd move to something like /docs/0.7/ for future releases, but I can't find any discussion about this in particular. We probably jumped to the conclusion that we only would have the current release and the current dev version. I agree with this new approach. So would it be like this ... Assuming that we don't want to version the top-level docs. Is that a legitimate assumption? It would change our layout if we do. I don't know the answer yet either. f.a.o/ ... the top-level docs, from trunk/site-author f.a.o/docs/ ... is .htaccess to redirect to current release docs. f.a.o/docs/0.6/ ... from the forrest_06_branch (*) f.a.o/docs/0.7/ ... from the forrest_07_branch, when it is released f.a.o/docs/0.8/ ... the next development, from future trunk/docs-author/ Let us see what the other solution would be. (Say that current release is 0.7) f.a.o/ ... the top-level docs, .htaccess to redirect to 0.7 top-level f.a.o/docs/ ... .htaccess to redirect to 0.7/docs/ f.a.o/0.6/ ... from the forrest_06_branch f.a.o/0.6/docs/ ... from the forrest_06_branch f.a.o/0.7/ ... from the forrest_07_branch/site-author/ f.a.o/0.7/docs/ ... from the forrest_07_branch/docs-author/ f.a.o/0.8/ ... the next development, from the trunk/site-author/ f.a.o/0.8/docs/ ... from the trunk/docs-author/ I have done local tests with both methods. The second way seems much easier and leaves more scope for the future. To use the first way, would also mean a re-structure of the docs part of forrest_06_branch. --David Furthering this idea, if we are versioning and storing docs-author and site-author, do we really need to store them seperately? As you said, this method would mean we won't have to restructure the forrest_06_branch docs into two parts. -- Dave Brondsema : [EMAIL PROTECTED] http://www.splike.com : programming http://csx.calvin.edu : student org http://www.brondsema.net : personal signature.asc Description: OpenPGP digital signature
Re: plugin naming convention
David Crossley wrote: I see that many of our plugins, even new ones, are not using the naming convention. ... snipped from plugins/pluginInfrastructure.html - org.apache.forrest.plugin.PLUGINNAME net.sf.forrestPlugins.PLUGINNAME In addition the name of the plugin should indicate the type of plugin it is: NAME-input NAME-output NAME-internal - Should we amend the existing names before the 0.7 release? Should we get plugins/build.xml seedPlugin target to append the -$type part. I forgot I'd written that ;-) The practice I have been following is that if it is an input plugin then it need not have the extension (given that most plugins are input. However, this is probably not ideal since it is an exception to the rule. I'd say that, for the 0.7 release we should make all the names conform to the documented standard and deprecate all the old plugins (this is OK since the plugin infrastructure is part of the 0.7-dev work). The idea of changing the build target is an excellent one too. Ross
Re: acknowledgement of contributors and author attribution
David Crossley wrote: ... For various reasons, the ASF Board suggested to all projects to remove authors from sources. Apache Forrest follows that recommendation. Prior to each release we scan the code to detect any license issues and any author tags. Om that case how about removing the developers section from status.xml DTD (we can still see who applied a patch or addition in the SVN logs if necessary). In addition we should consider removing the author tag from the document.xml 2.0 DTD Ross
Re: clean up the plugins
David Crossley wrote: I started going through the plugins to fix any major issues before the release. The /plugins/ area of the website has some old *.zip for the plugins that have been renamed ... OpenOffice.org.zip feeder.zip htmlArea.zip text-output.zip Should i remove them from the forrest-site/plugins/ SVN? Yes, this is something I've been thinking about recently. The SVN is going to get into a mess since we update when deploying a plugin but there is no way to clean it up. We will probably need a periodic tidy up. I think it should certainly be part of the release process. Ross
Re: 2nd generation skinning - view and leather
Thorsten Scherler wrote: If somebody have some spare time and want to help us with the 2nd generation skinning you can: I will certainly be helping out, but not until 0.7 is released. Once that is done this is right at the top of my ToDo list. Ross
Re: 2nd generation skinning - view and leather
Thorsten Scherler wrote: On Mon, 2005-04-04 at 20:42 +0100, Ross Gardler wrote: Thorsten Scherler wrote: If somebody have some spare time and want to help us with the 2nd generation skinning you can: I will certainly be helping out, but not until 0.7 is released. Once that is done this is right at the top of my ToDo list. Dude, no hurries. You know more or less know what I am trying to do. Now I need more devs/user and committer (junior/senior) looking in the stuff and give me/us feedback. I think it would be a good idea to plan the view/leather as default skinning mechanism for 0.8. That would makes it possible to develop the skinning engine for 0.9 and have a stable version on our 1.0. :) I'd be +1 for this, especially since you have stated that your goal is to make the new system use an XHTML internal format, which is already a 0.8 deliverable. ...but for that I need some eyes on the code and NOT ONLY yours and mine!!! Actually I wish especially that Nicola would have a look and play devils advocate. ;-) I noticed a Blog from Nicola recently saying he has stopped getting involved with too many planning discussions as he has found himself too distracted. He also mentioned he unsubscribed from lots of lists. I hope this wasn't one of them. Nicola, being Nicola, if he is here he'll have filters to pick, out emails with his name in, so if we mention Nicola a few times, maybe by his alternative moniker of Nicola Ken, he might get flagged by his filter systems. Nicola Ken, we need your input (you don't need to volunteer for anything or code anything - and we'll be happy to give you a catch-up mail ;-) OK, if that doesn't work - then he's gone for a while (I'm resisting sending a personal mail...) Ross
[JIRA] Commented: (FOR-340) plugin build file
The following comment has been added to this issue: Author: Ross Gardler Created: Mon, 4 Apr 2005 5:01 PM Body: We also need a summary of plugin functionality in the fresh-site template. This should be generated when a user runs forrest seed, that is it retrieves the official plugins.xml file and transforms it into an XDoc. - View this comment: http://issues.cocoondev.org//browse/FOR-340?page=comments#action_12202 - View the issue: http://issues.cocoondev.org//browse/FOR-340 Here is an overview of the issue: - Key: FOR-340 Summary: plugin build file Type: Improvement Status: Open Priority: Minor Project: Forrest Components: Plugins (general issues) Fix Fors: 0.8 Versions: 0.7-dev Assignee: Ross Gardler Reporter: Ross Gardler Created: Sat, 30 Oct 2004 7:05 PM Updated: Mon, 4 Apr 2005 5:01 PM Description: A build file is required to aid the management of plugins, this build file should: - build the distribution version of one or more plugins - update the plugins.xml file in forrestcore - upload plugin distributions to their distribution server - build the plugin documentation - upload the plugin documentation to its web space - upload the src documentation to the repository location - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: svn commit: r160109 - in forrest/site/plugins/docs/org.apache.forrest.plugin.OpenOffice.org: ./ skin/ skin/screen.css
[EMAIL PROTECTED] wrote: Author: rgardler Date: Mon Apr 4 15:13:48 2005 New Revision: 160109 URL: http://svn.apache.org/viewcvs?view=revrev=160109 Log: Deployment of org.apache.forrest.plugin.OpenOffice.org plugin (deployed by 'deploy' target of plugin build script) Added: forrest/site/plugins/docs/org.apache.forrest.plugin.OpenOffice.org/ forrest/site/plugins/docs/org.apache.forrest.plugin.OpenOffice.org/skin/ forrest/site/plugins/docs/org.apache.forrest.plugin.OpenOffice.org/skin/screen.css OK, I'm experimenting with auto generating plugin docs, so you may see a few of these kinds of commits over then next week as I grab an hour here an hour there. But I have some questions. I've not really kept up to date with the docs discussions, either the first round or this round. I'm afraid they slipped underneath my full attention threshold. Now I find I should have kept up. How do people suggest I integrate the plugin docs with the main website docs? As the above commit shows, I have a new deploy target that will update the docs at forrest.apache.org/plugins/docs/PLUGIN-NAME each time a plugin is deployed with ant deploy I intend to create an index page to go into that directory from the plugins.xml file. How do we link from the main docs-author (or site-author?) part of the site? Ross
Re: [JIRA] Closed: (FOR-450) Input plugins broken
On Mon, 2005-04-04 at 15:52 -0500, [EMAIL PROTECTED] wrote: My testing turns up not issues, so , once again, thanks for finding this Rick, I'd gone blind to the problem and it was driving me mad! No worries! Sometimes all it takes is a fresh pair of eyes. :) -- Rick Tessner rick at apache dot org smime.p7s Description: S/MIME cryptographic signature
Re: plugin naming convention
Ross Gardler wrote: David Crossley wrote: I see that many of our plugins, even new ones, are not using the naming convention. ... snipped from plugins/pluginInfrastructure.html - org.apache.forrest.plugin.PLUGINNAME net.sf.forrestPlugins.PLUGINNAME In addition the name of the plugin should indicate the type of plugin it is: NAME-input NAME-output NAME-internal - Should we amend the existing names before the 0.7 release? Should we get plugins/build.xml seedPlugin target to append the -$type part. I forgot I'd written that ;-) The practice I have been following is that if it is an input plugin then it need not have the extension (given that most plugins are input. However, this is probably not ideal since it is an exception to the rule. I'd say that, for the 0.7 release we should make all the names conform to the documented standard and deprecate all the old plugins (this is OK since the plugin infrastructure is part of the 0.7-dev work). Why deprecate? Rather we should just rename (and mention the consolidation in changelog). --David The idea of changing the build target is an excellent one too. Ross
Re: acknowledgement of contributors and author attribution
Ross Gardler wrote: David Crossley wrote: For various reasons, the ASF Board suggested to all projects to remove authors from sources. Apache Forrest follows that recommendation. Prior to each release we scan the code to detect any license issues and any author tags. Om that case how about removing the developers section from status.xml DTD (we can still see who applied a patch or addition in the SVN logs if necessary). Or make it optional. At the moment i am just working around that like this: org.apache.forrest.plugin.dtdx-input/status.xml status developers person name=Volunteer needed email=dev@forrest.apache.org id=open/ /developers changes release version=0.1 date=unreleased action dev=DC type=add context=admin Initial plugin, moving stuff out of forrest core. /action ... We can still use the committer's initials in the changelog. In addition we should consider removing the author tag from the document.xml 2.0 DTD It is already optional, so no need to remove it. Anyway, other people might be using these DTDs and they might want the author tags. --David
Re: 2nd generation skinning - view and leather
Ross Gardler wrote: Thorsten Scherler wrote: Ross Gardler wrote: Thorsten Scherler wrote: If somebody have some spare time and want to help us with the 2nd generation skinning you can: I will certainly be helping out, but not until 0.7 is released. Once that is done this is right at the top of my ToDo list. Yep, getting 0.7 out is my priority too. I am trying to resist the urge to look at new stuff and instead consolidate. Dude, no hurries. You know more or less know what I am trying to do. Now I need more devs/user and committer (junior/senior) looking in the stuff and give me/us feedback. I think it would be a good idea to plan the view/leather as default skinning mechanism for 0.8. That would makes it possible to develop the skinning engine for 0.9 and have a stable version on our 1.0. :) I'd be +1 for this, especially since you have stated that your goal is to make the new system use an XHTML internal format, which is already a 0.8 deliverable. ...but for that I need some eyes on the code and NOT ONLY yours and mine!!! Actually I wish especially that Nicola would have a look and play devils advocate. ;-) I noticed a Blog from Nicola recently saying he has stopped getting involved with too many planning discussions as he has found himself too distracted. He also mentioned he unsubscribed from lots of lists. I hope this wasn't one of them. Nicola, being Nicola, if he is here he'll have filters to pick, out emails with his name in, so if we mention Nicola a few times, maybe by his alternative moniker of Nicola Ken, he might get flagged by his filter systems. Nicola Ken, we need your input (you don't need to volunteer for anything or code anything - and we'll be happy to give you a catch-up mail ;-) OK, if that doesn't work - then he's gone for a while (I'm resisting sending a personal mail...) I too hope that works, but don't rely on anyone, not saying that Nicola Ken isn't. --David
