clean up the plugins
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? --David
2nd generation skinning - view and leather
Hello devs, I splitted views into view and leather. view Is an internal plugin which prepares the presentation stage by calling all needed content and add it to the pipeline. Right now we are hooking in the last stage (site2xhtml) of the core skinit pipes. leather Is an output plugin which provides the contract implementations requested by the view. This contracts have been extracted from the site2xhtml.xsl from leather-dev. Trying to say that the contracts are xsl-templates. Everything seems to work the way I expected. Now I have to finish all contracts from leather/pelt (leather), move all skin core pipes that are requesting content to the (view) and document everything very well. ;-) If somebody have some spare time and want to help us with the "2nd generation skinning" you can: - help implementing the missing contracts from pelt/leather into forrest:templates - provide css enhancement for the leather plugin skin - look into the skin core pipes and move them over to the view plugin - write documentation salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
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: problem with docs at forrest.apache.org/docs/dev/
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
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'
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. > > > 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'. --David
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
[JIRA] Closed: (FOR-450) Input plugins broken
Message: The following issue has been closed. Resolver: Ross Gardler Date: Mon, 4 Apr 2005 3:52 PM 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! - View the issue: http://issues.cocoondev.org//browse/FOR-450 Here is an overview of the issue: - Key: FOR-450 Summary: Input plugins broken Type: Bug Status: Closed Priority: Blocker Resolution: FIXED Project: Forrest Components: Plugins (general issues) Fix Fors: 0.7-dev Versions: 0.7-dev Assignee: Rick Tessner Reporter: Ross Gardler Created: Mon, 28 Feb 2005 4:34 PM Updated: Mon, 4 Apr 2005 3:52 PM Description: Input plugins are not working in Head. Unfortunately I do not have the time to find the cause right now. What I can say is that r153977 works fine. - 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: 2nd generation skinning - view and leather
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. :)
...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. ;-)
David had a look on it this morning (I am still waiting for things you
do [not] like). ;-)
Sorry for being pain in the a***, but I need some enhancement suggestion
because I am relative happy with the concept but not really with my
implementation (it is still proof of concept). ;-)
One important thing IMO is to officially define an interface for skins
and views. Leather has it (e.g.
cocoon://get.contract.{contract-name}.{format}) but as well contains the
implementations. I reckon the given example match would be better of in
the view plugin which define the interface.
New skins would need only to provide new implementations of contracts
and not define the interface again. That will make it necessary to
change some matches but actually I only have not implemented it yet to
not deciding the future of skins all by myself and bringing more
complexity to the things I am doing.
Talking about complexity, I was teaching my students the MVC pattern and
must admit that I see our nuggets as result of models. This models
depend on the document specific meta data (forrest:properties). They
deliver our intermediate format.
Now the view/leather plugins are a mix of controller and view in my eyes
that is the reason (I guess) Ross et. al. having problems to understand
me because I am mixing things in the code and do not have a clear
separation.
...and that is the reason why I need feedback. ;-)
TIA
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
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=rev&rev=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 Initial plugin, moving stuff out of forrest core. ... 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
Re: problem with docs at forrest.apache.org/docs/dev/
Dave Brondsema wrote: > [snip] > 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. Good point. This separation is actually causing grief for the off-line docs, as we cannot link from one to the other. I looked back through the email threads on FOR-391 and it seems that we made an assumption leap to have the docs-author and site-author split. There was a passing comment that we might have it like Cocoon where they have a completely separate svn:cocoon/site/ to hold the top-level docs. We didn't talk about the consequences. So coming back to the current proposal, the only issue that i see is that we will have multiple versions of the top-level docs. I don't see that as a problem because we will have multiple versions of /docs/ anyway and they will have a banner saying "this is version x.y". --David
