You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by David Crossley <cr...@apache.org> on 2005/08/19 04:46:51 UTC
using the plugin status.xml (Was: svn commit: r233401)
I think that notes about changes like this should go into
the status.xml in each plugin, and keep this top-level
status for high-level notes about major changes in
each plugin.
-David
> Author: thorsten
> Date: Thu Aug 18 17:44:00 2005
> New Revision: 233401
>
> URL: http://svn.apache.org/viewcvs?rev=233401&view=rev
> Log:
> Refactored the view resolver code of the internal.view plugin. Created an action that is doing the same as before the combination of sitemap+xsl.
> Added 2 java classes to package org.apache.forrest.plugin.internal.view.acting:
> 1.FallbackResolverAction.java
> 2.FallbackResolverHelper.java
[snip]
> ==============================================================================
> --- forrest/trunk/site-author/status.xml (original)
> +++ forrest/trunk/site-author/status.xml Thu Aug 18 17:44:00 2005
> @@ -131,6 +131,32 @@
> <link href="site:v0.80//upgrading_08">upgrading to v0.8</link>
> </action>
>
> + <action context="code" type="add" dev="TS">
> + Refactored the view resolver code of the internal.view plugin. Created an action that
> + is doing the same as before the combination of sitemap+xsl. <br/>Added 2 java classes to package
> + org.apache.forrest.plugin.internal.view.acting:<br/>
> + 1.FallbackResolverAction.java<br/>2.FallbackResolverHelper.java
> + </action>
> +
> + <action context="code" type="add" dev="TS">
> + Removed project.view-defaultView properties and added project.theme-extension instead. The combination
> + of project.theme-extension and project.theme is equal to project.view-defaultView.
> + </action>
> +
> + <action context="code" type="add" dev="TS">
> + Added new elements to org.apache.forrest.conf.ForrestConfModule name="defaults":
> + <br/> view-themes<br/>theme-ext<br/>theme<br/>
> + </action>
> +
> + <action context="code" type="add" dev="TS">
> + Removed "defaultView" and added new element to org.apache.forrest.conf.ForrestConfModule name="project":
> + <br/>theme-ext
> + </action>
> +
> + <action context="code" type="add" dev="TS">
> + normalize-space() the forrest:properties before parsing them to the pipe
> + </action>
> +
> <action type="add" context="docs" fixes-bug="FOR-603"
> due-to="Addison Berry">
> Added document to explain the process for
Re: using the plugin status.xml (Was: svn commit: r233401)
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> Thorsten Scherler wrote:
>
>> On Fri, 2005-08-19 at 12:46 +1000, David Crossley wrote:
>>
>>> I think that notes about changes like this should go into
>>> the status.xml in each plugin, and keep this top-level
>>> status for high-level notes about major changes in
>>> each plugin.
>>
>>
>>
>> Thanks for bringing this up, David.
>>
>> In general I agree with you because normally you make changes only in
>> the plugin. That means you just use one status.xml.
>
>
> Maybe be this commit only touched one of those plugins. C'mon admit it,
> this is your lazy side coming through ;-)
Ooopsss... sorry I just read the commit messages and see you did do
entries in status.xml - not so lazy as you claimed in Stuttgart ;-)
The inclusion of upgrade instructions (below) is still a good tip
though. In fact, if you do <p class="instruction">, they will be
displayed as instructions in the reports. (I think, not tested)
Ross
> These kinds of changes should go into status.xml with an
> @importance="high" tag (so they appear in the overview changes
> document). You should also include upgrade instructions (like those
> posted in your heads-up ail) so that we don't lose them.
>
> I knows it's a little more work for you, but it really would make
> everybody elses job in tracking your excellent work easier.
>
> ---
>
> With respect to the "three plugins problem", we need to discuss this in
> a different thread. I have a plugin waiting for release which has an
> unresolvable dependency on the OOo plugin. Therefore we need to crete
> the equivalent of a feature in Eclipse (a collection of plugins).
>
> One of us should start that thread when we have time to follow it through.
>
> Ross
>
>
Re: using the plugin status.xml (Was: svn commit: r233401)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Fri, 2005-08-19 at 12:46 +1000, David Crossley wrote:
>
>>I think that notes about changes like this should go into
>>the status.xml in each plugin, and keep this top-level
>>status for high-level notes about major changes in
>>each plugin.
>
>
> Thanks for bringing this up, David.
>
> In general I agree with you because normally you make changes only in
> the plugin. That means you just use one status.xml.
Maybe be this commit only touched one of those plugins. C'mon admit it,
this is your lazy side coming through ;-)
These kinds of changes should go into status.xml with an
@importance="high" tag (so they appear in the overview changes
document). You should also include upgrade instructions (like those
posted in your heads-up ail) so that we don't lose them.
I knows it's a little more work for you, but it really would make
everybody elses job in tracking your excellent work easier.
---
With respect to the "three plugins problem", we need to discuss this in
a different thread. I have a plugin waiting for release which has an
unresolvable dependency on the OOo plugin. Therefore we need to crete
the equivalent of a feature in Eclipse (a collection of plugins).
One of us should start that thread when we have time to follow it through.
Ross
Re: using the plugin status.xml (Was: svn commit: r233401)
Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2005-08-19 at 12:46 +1000, David Crossley wrote:
> I think that notes about changes like this should go into
> the status.xml in each plugin, and keep this top-level
> status for high-level notes about major changes in
> each plugin.
Thanks for bringing this up, David.
In general I agree with you because normally you make changes only in
the plugin. That means you just use one status.xml.
Now in the case of views I have 3 different plugins and since views is
growing to the core as well the main webapp status.xml. Like with the
documentation of views that are *too* many places. It is very hard to
follow what is going on if you force somebody that is interested in
views to check 4 different status.xml.
BTW most of the changes I made, *are* major and this will not change
till we refactored all the views code (where possible) to java
components like I started with this commit.
I would like to propose a component based status for views.
status-views.xml - this would be the status file for all views related
changes to the 3 plugins and core.
WDYT?
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)