You are viewing a plain text version of this content. The canonical link for it is here.
Posted to svn@forrest.apache.org by th...@apache.org on 2005/09/28 01:59:42 UTC
svn commit: r292072 - in /forrest/trunk/whiteboard/plugins:
org.apache.forrest.plugin.internal.structurer/
org.apache.forrest.plugin.internal.structurer/lib/
org.apache.forrest.plugin.internal.structurer/resources/
org.apache.forrest.plugin.internal.st...
Author: thorsten
Date: Tue Sep 27 16:59:14 2005
New Revision: 292072
URL: http://svn.apache.org/viewcvs?rev=292072&view=rev
Log:
Added two new plugins for
refactoring views into the core:
- structurer
- themes
Recent changes to views with using jxtg as core component
made the old view plugins unusable (FOR-675)
which can not longer stay like this.
I recommend to rollback:
- org.apache.forrest.plugin.internal.view
- org.apache.forrest.plugin.output.viewHelper.xhtml
to revision -r280939 and then commit them back as views head.
The changes not related to jx could be readded via patches from svn log.
This will solve FOR-678 for old views plugin and use the new plugins
to incoperate forrest:views into the core.
The new plugins will still suffer from FOR-678!
Added:
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/
- copied from r292068, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/build.xml
- copied unchanged from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/build.xml
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/dataModel.xmap
- copied unchanged from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/dataModel.xmap
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/forrest.properties
- copied unchanged from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/forrest.properties
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/internal.xmap
- copied unchanged from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/internal.xmap
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/lib/
- copied from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/lib/
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/menu.xmap
- copied unchanged from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/menu.xmap
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/resources/
- copied from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/resources/
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/src/
- copied from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/src/
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/status.xml
- copied unchanged from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/status.xml
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/tabs.xmap
- copied unchanged from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/tabs.xmap
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themes/
- copied from r292068, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themes/build.xml
- copied unchanged from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/build.xml
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themes/forrest.properties
- copied unchanged from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/forrest.properties
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themes/jtidy.properties
- copied unchanged from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/jtidy.properties
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themes/messages/
- copied from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/messages/
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themes/output.xmap
- copied unchanged from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/output.xmap
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themes/resources/
- copied from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/resources/
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themes/resources.xmap
- copied unchanged from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/resources.xmap
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themes/src/
- copied from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/src/
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themes/status.xml
- copied unchanged from r292071, forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/status.xml
Re: status of "views" development (Was: svn commit: r292072)
Posted by Thorsten Scherler <th...@apache.org>.
El mié, 05-10-2005 a las 12:15 +1000, David Crossley escribió:
> Thorsten Scherler wrote:
> > David Crossley escribi??:
> > > Thorsten Scherler wrote:
> > > > David Crossley escribi??:
> > > > > Thorsten Scherler wrote:
> > > > > > for the new plugins because the contracts have to request all content
> > > > > > that they are using. There is no default pipeline anymore.
> > > > >
> > > > > What! Do you mean also the original source which provides
> > > > > the main content?
> > > >
> > > > Per definition there is no main content anymore. That is why I always
> > > > said views are going to change forrest from ground up. In combination
> > > > with the lm forrest could be used as renderer only.
> > >
> > > What "definition" are you referring to?
> >
> > The J2EE dispatcher view pattern.
> >
> > > I am going by the description at
> > > site-author/content/xdocs/TR/2005/WD-forrest10.html
> > >
> > > The first two steps provide the initial content via an
> > > input plugin, then views operate from Step 3 onwards
> > > adding more content nuggets, functionality, and design.
> >
> > No:
> > request theme
> > | |
> > \|/ \|/
> > core (views) -> output plugin (views can bypass them) -> output/response
> > | /|\
> > \|/ |
> > +------------------+ +-----------------+
> > |forrest:contracts |--->| input plugin |
> > |forrest:properties|<---|src (+navigation)|
> > +------------------+ +-----------------+
> >
> > View is the one and only dispatcher that will only request what is
> > needed. We do not have a linear processing anymore. Views are
> > responsible to contact the src-resolver (1.) and dispatch/filter (2.).
> > What I am trying to say (since my work with views started) is that 3. is
> > done in the dispatching phase to not carrying content down the pipe that
> > is not needed.
>
> > Views are more then a structurer, mainly it is a
> > dispatcher.
> >
> > IMO it should be:
> > 1) Resolver (view)
> > 2) Filter (content as dispatched and determined by the view)
> > 3) Xifier (content)
> > 4) Windower (presentation)
> > 5) Themer (presentation)
> > 6) Serializer (presentation)
>
> I will need to read and re-read to digest that.
>
> The reason that i got concerned, and still am, is that
> i have an input plugin that does pre-processing
> of the initial source, e.g. request two different
> sources, process them separately and aggregate them
> using multiple sitemap matches, and then provide the
> unified source as a table for the rest of forrest
> to handle. Can views "contracts" do such complex
> processing involving Cocoon pipelines, or are they
> restricted to simple single xsl tasks?
jeje
They can do much more then simple xsl. That is "just" the viewHelper
part. View helper are doing mainly transformation.
nugget-contracts are used to connect input plugins or any other business
service that provide data. They can e.g. contact your input plugin and
get the aggregate or you can let views collect everything. That is
finally a design decision. The only condition that have to be meet that
you can connect this services through cocoon://something. Where
something can be as well any uri.
Hope that explains it a bit better, please keep on asking. ;-)
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: status of "views" development (Was: svn commit: r292072)
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> David Crossley escribi??:
> > Thorsten Scherler wrote:
> > > David Crossley escribi??:
> > > > Thorsten Scherler wrote:
> > > > > for the new plugins because the contracts have to request all content
> > > > > that they are using. There is no default pipeline anymore.
> > > >
> > > > What! Do you mean also the original source which provides
> > > > the main content?
> > >
> > > Per definition there is no main content anymore. That is why I always
> > > said views are going to change forrest from ground up. In combination
> > > with the lm forrest could be used as renderer only.
> >
> > What "definition" are you referring to?
>
> The J2EE dispatcher view pattern.
>
> > I am going by the description at
> > site-author/content/xdocs/TR/2005/WD-forrest10.html
> >
> > The first two steps provide the initial content via an
> > input plugin, then views operate from Step 3 onwards
> > adding more content nuggets, functionality, and design.
>
> No:
> request theme
> | |
> \|/ \|/
> core (views) -> output plugin (views can bypass them) -> output/response
> | /|\
> \|/ |
> +------------------+ +-----------------+
> |forrest:contracts |--->| input plugin |
> |forrest:properties|<---|src (+navigation)|
> +------------------+ +-----------------+
>
> View is the one and only dispatcher that will only request what is
> needed. We do not have a linear processing anymore. Views are
> responsible to contact the src-resolver (1.) and dispatch/filter (2.).
> What I am trying to say (since my work with views started) is that 3. is
> done in the dispatching phase to not carrying content down the pipe that
> is not needed.
> Views are more then a structurer, mainly it is a
> dispatcher.
>
> IMO it should be:
> 1) Resolver (view)
> 2) Filter (content as dispatched and determined by the view)
> 3) Xifier (content)
> 4) Windower (presentation)
> 5) Themer (presentation)
> 6) Serializer (presentation)
I will need to read and re-read to digest that.
The reason that i got concerned, and still am, is that
i have an input plugin that does pre-processing
of the initial source, e.g. request two different
sources, process them separately and aggregate them
using multiple sitemap matches, and then provide the
unified source as a table for the rest of forrest
to handle. Can views "contracts" do such complex
processing involving Cocoon pipelines, or are they
restricted to simple single xsl tasks?
-David
Re: status of "views" development (Was: svn commit: r292072)
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 04-10-2005 a las 19:20 +1000, David Crossley escribió:
> Thorsten Scherler wrote:
> > David Crossley escribi??:
> > > Thorsten Scherler wrote:
> > > > for the new plugins because the contracts have to request all content
> > > > that they are using. There is no default pipeline anymore.
> > >
> > > What! Do you mean also the original source which provides
> > > the main content?
> >
> > Per definition there is no main content anymore. That is why I always
> > said views are going to change forrest from ground up. In combination
> > with the lm forrest could be used as renderer only.
>
> What "definition" are you referring to?
The J2EE dispatcher view pattern.
> I am going by the description at
> site-author/content/xdocs/TR/2005/WD-forrest10.html
>
> The first two steps provide the initial content via an
> input plugin, then views operate from Step 3 onwards
> adding more content nuggets, functionality, and design.
No:
request theme
| |
\|/ \|/
core (views) -> output plugin (views can bypass them) -> output/response
| /|\
\|/ |
+------------------+ +-----------------+
|forrest:contracts |--->| input plugin |
|forrest:properties|<---|src (+navigation)|
+------------------+ +-----------------+
View is the one and only dispatcher that will only request what is
needed. We do not have a linear processing anymore. Views are
responsible to contact the src-resolver (1.) and dispatch/filter (2.).
What I am trying to say (since my work with views started) is that 3. is
done in the dispatching phase to not carrying content down the pipe that
is not needed. Views are more then a structurer, mainly it is a
dispatcher.
IMO it should be:
1) Resolver (view)
2) Filter (content as dispatched and determined by the view)
3) Xifier (content)
4) Windower (presentation)
5) Themer (presentation)
6) Serializer (presentation)
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: status of "views" development (Was: svn commit: r292072)
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> David Crossley escribi??:
> > Thorsten Scherler wrote:
> > > for the new plugins because the contracts have to request all content
> > > that they are using. There is no default pipeline anymore.
> >
> > What! Do you mean also the original source which provides
> > the main content?
>
> Per definition there is no main content anymore. That is why I always
> said views are going to change forrest from ground up. In combination
> with the lm forrest could be used as renderer only.
What "definition" are you referring to?
I am going by the description at
site-author/content/xdocs/TR/2005/WD-forrest10.html
The first two steps provide the initial content via an
input plugin, then views operate from Step 3 onwards
adding more content nuggets, functionality, and design.
-David
Re: status of "views" development (Was: svn commit: r292072)
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 04-10-2005 a las 17:26 +1000, David Crossley escribió:
> Thorsten Scherler wrote:
> > David Crossley escribi??:
> > ...
> > > The views development is now in two new plugins:
> > > * internal.structurer (which was copied from internal.view)
> > > * output.themes (which was copied from output.viewHelper.xhtml)
> > >
> > > The input.viewHelper.xhtml.ls plugin is still relevant to
> > > get a list of contracts.
> >
> > > Development of the old plugins has now ceased. The last
> > > working version was SVN revision r292708.
> > >
> >
> > That is right. The "new" version of views, that are will be used in the
> > future are in the new plugins. They are based on jx-templates.
> >
> > > Documentation will need to be changed.
> >
> > for the new plugins because the contracts have to request all content
> > that they are using. There is no default pipeline anymore.
>
> What! Do you mean also the original source which provides
> the main content?
Per definition there is no main content anymore. That is why I always
said views are going to change forrest from ground up. In combination
with the lm forrest could be used as renderer only.
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: status of "views" development (Was: svn commit: r292072)
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> David Crossley escribi??:
> ...
> > The views development is now in two new plugins:
> > * internal.structurer (which was copied from internal.view)
> > * output.themes (which was copied from output.viewHelper.xhtml)
> >
> > The input.viewHelper.xhtml.ls plugin is still relevant to
> > get a list of contracts.
>
> > Development of the old plugins has now ceased. The last
> > working version was SVN revision r292708.
> >
>
> That is right. The "new" version of views, that are will be used in the
> future are in the new plugins. They are based on jx-templates.
>
> > Documentation will need to be changed.
>
> for the new plugins because the contracts have to request all content
> that they are using. There is no default pipeline anymore.
What! Do you mean also the original source which provides
the main content?
-David
Re: status of "views" development (Was: svn commit: r292072)
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 04-10-2005 a las 13:22 +1000, David Crossley escribió:
...
> The views development is now in two new plugins:
> * internal.structurer (which was copied from internal.view)
> * output.themes (which was copied from output.viewHelper.xhtml)
>
> The input.viewHelper.xhtml.ls plugin is still relevant to
> get a list of contracts.
> Development of the old plugins has now ceased. The last
> working version was SVN revision r292708.
>
That is right. The "new" version of views, that are will be used in the
future are in the new plugins. They are based on jx-templates.
> Documentation will need to be changed.
for the new plugins because the contracts have to request all content
that they are using. There is no default pipeline anymore.
Cheers David to summarize this.
salu2
> -David
>
> > Author: thorsten
> > Date: Tue Sep 27 16:59:14 2005
> > New Revision: 292072
> >
> > URL: http://svn.apache.org/viewcvs?rev=292072&view=rev
> > Log:
> > Added two new plugins for
> > refactoring views into the core:
> > - structurer
> > - themes
> >
> > Recent changes to views with using jxtg as core component
> > made the old view plugins unusable (FOR-675)
> > which can not longer stay like this.
> >
> > I recommend to rollback:
> > - org.apache.forrest.plugin.internal.view
> > - org.apache.forrest.plugin.output.viewHelper.xhtml
> > to revision -r280939 and then commit them back as views head.
> >
> > The changes not related to jx could be readded via patches from svn log.
> >
> > This will solve FOR-678 for old views plugin and use the new plugins
> > to incoperate forrest:views into the core.
> >
> > The new plugins will still suffer from FOR-678!
> >
> > [snip copied files]
> >
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: status of "views" development (Was: svn commit: r292072)
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
>
>> So i am going to try to summarise so that we can
>> continue to work in Thorsten's absence..
>>
>> The views development is now in two new plugins:
>> * internal.structurer (which was copied from internal.view)
>> * output.themes (which was copied from output.viewHelper.xhtml)
>
>
> Yes
>
> Although Thorsten has asked us not to do anything with respect to the
> Locationmap, which makes things kind of difficult. He's on IRC right
> now, I'm going to address this with him and see where we can get to.
Summary of IRC input from Thorsten...
The problem is that JXPath is breaking site: and ext: protocols and so
the work on his hard disk is broken. Hence not committing yet (I guess).
He needs help getting JXPath to work.
Over on IRC I just made a radical suggestion, that is currently being
discussed. I'm having to leave for a few hours. hopefully an update will
be available when I return.
Stay tuned....
Ross
Re: status of "views" development (Was: svn commit: r292072)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> So i am going to try to summarise so that we can
> continue to work in Thorsten's absence..
>
> The views development is now in two new plugins:
> * internal.structurer (which was copied from internal.view)
> * output.themes (which was copied from output.viewHelper.xhtml)
Yes
Although Thorsten has asked us not to do anything with respect to the
Locationmap, which makes things kind of difficult. He's on IRC right
now, I'm going to address this with him and see where we can get to.
> The input.viewHelper.xhtml.ls plugin is still relevant to
> get a list of contracts.
Yes
> Development of the old plugins has now ceased. The last
> working version was SVN revision r292708.
Yes
> Documentation will need to be changed.
Actually this has to happen with respect to the old views as well as the
two are way out of sync. Probably not worth it though
>
> -David
>
>
>>Author: thorsten
>>Date: Tue Sep 27 16:59:14 2005
>>New Revision: 292072
>>
>>URL: http://svn.apache.org/viewcvs?rev=292072&view=rev
>>Log:
>>Added two new plugins for
>>refactoring views into the core:
>>- structurer
>>- themes
>>
>>Recent changes to views with using jxtg as core component
>>made the old view plugins unusable (FOR-675)
>>which can not longer stay like this.
>>
>>I recommend to rollback:
>>- org.apache.forrest.plugin.internal.view
>>- org.apache.forrest.plugin.output.viewHelper.xhtml
>>to revision -r280939 and then commit them back as views head.
>>
>>The changes not related to jx could be readded via patches from svn log.
>>
>>This will solve FOR-678 for old views plugin and use the new plugins
>>to incoperate forrest:views into the core.
>>
>>The new plugins will still suffer from FOR-678!
>>
>>[snip copied files]
>>
>
>
>
status of "views" development (Was: svn commit: r292072)
Posted by David Crossley <cr...@apache.org>.
So i am going to try to summarise so that we can
continue to work in Thorsten's absence..
The views development is now in two new plugins:
* internal.structurer (which was copied from internal.view)
* output.themes (which was copied from output.viewHelper.xhtml)
The input.viewHelper.xhtml.ls plugin is still relevant to
get a list of contracts.
Development of the old plugins has now ceased. The last
working version was SVN revision r292708.
Documentation will need to be changed.
-David
> Author: thorsten
> Date: Tue Sep 27 16:59:14 2005
> New Revision: 292072
>
> URL: http://svn.apache.org/viewcvs?rev=292072&view=rev
> Log:
> Added two new plugins for
> refactoring views into the core:
> - structurer
> - themes
>
> Recent changes to views with using jxtg as core component
> made the old view plugins unusable (FOR-675)
> which can not longer stay like this.
>
> I recommend to rollback:
> - org.apache.forrest.plugin.internal.view
> - org.apache.forrest.plugin.output.viewHelper.xhtml
> to revision -r280939 and then commit them back as views head.
>
> The changes not related to jx could be readded via patches from svn log.
>
> This will solve FOR-678 for old views plugin and use the new plugins
> to incoperate forrest:views into the core.
>
> The new plugins will still suffer from FOR-678!
>
> [snip copied files]
>
Re: [Proposal] rollback
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 27-09-2005 a las 21:41 -0700, Diwaker Gupta escribió:
> On Tuesday 27 September 2005 5:08 pm, Thorsten Scherler wrote:
> > > Added two new plugins for
> > > refactoring views into the core:
> > > - structurer
> > > - themes
> > >
> > > Recent changes to views with using jxtg as core component
> > > made the old view plugins unusable (FOR-675)
> > > which can not longer stay like this.
> > >
> > > I recommend to rollback:
> > > - org.apache.forrest.plugin.internal.view
> > > - org.apache.forrest.plugin.output.viewHelper.xhtml
> > > to revision -r280939 and then commit them back as views head.
>
> Why can't we just roll back trunk to a stable version, and move the
> views/xhtml2 work to a new branch?
That is what this proposal is about. The only unstable things that broke
trunk is views. Right now we do not need the branch but we create them.
> I think thats much neater, and easier both
> on devs and users alike. People can hack away on the views/xhtml2 branch
> without having to worry about breaking trunk for someone.
Yes I agree.
We can copy the current trunk to a new branch, rollback the views
plugins in the current trunk and pin them down. Then instead of using
the two new plugins we use trunk.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [Proposal] rollback
Posted by Thorsten Scherler <th...@apache.org>.
Done.
BTW using --force for svn is evil because it will haunt you! ;-) I
needed to delete a contract that I once added/modified with --force.
Log:
cd
$FORREST_HOME/whiteboard/plugins/org.apache.forrest.plugin.internal.view
svn merge -r HEAD:280939
https://svn.apache.org/repos/asf/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view
cd
$FORREST_HOME/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml
svn merge -r HEAD:280939
https://svn.apache.org/repos/asf/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml
Further development (and changes happened to the plugins after -r280939)
will happen (are) in
https://svn.apache.org/repos/asf/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themes
https://svn.apache.org/repos/asf/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer
The views plugin are now stable.
More information about approach taken to do the rollback:
http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.2
salu2
El jue, 29-09-2005 a las 23:23 +0200, Thorsten Scherler escribió:
> I reverted the plugins and keep working on the new plugins till we
> settle this discussion about branching or not.
>
> That makes user and dev using views like they were used to do before.
>
> salu2
>
> El jue, 29-09-2005 a las 10:46 +1000, David Crossley escribió:
> > Ross Gardler wrote:
> > > Diwaker Gupta wrote:
> > > >Thorsten Scherler wrote:
> > > >
> > > >>>Added two new plugins for
> > > >>>refactoring views into the core:
> > > >>>- structurer
> > > >>>- themes
> > > >>>
> > > >>>Recent changes to views with using jxtg as core component
> > > >>>made the old view plugins unusable (FOR-675)
> > > >>>which can not longer stay like this.
> > > >>>
> > > >>>I recommend to rollback:
> > > >>>- org.apache.forrest.plugin.internal.view
> > > >>>- org.apache.forrest.plugin.output.viewHelper.xhtml
> > > >>>to revision -r280939 and then commit them back as views head.
> > > >
> > > >Why can't we just roll back trunk to a stable version, and move the
> > > >views/xhtml2 work to a new branch? I think thats much neater, and easier
> > > >both on devs and users alike. People can hack away on the views/xhtml2
> > > >branch without having to worry about breaking trunk for someone.
> > >
> > > +1
> > >
> > > In fact this is exactly what we agreed in the IRC session:
> > >
> > > Sep 19 11:17:31 <tscherler> - we should get the xhtml2 and view internal
> > > together
> > > Sep 19 11:18:03 <tscherler> - xhtml2 should be merged into the internal
> > > views stuff, simply replace the docuemnt2html part
> > > Sep 19 11:18:42 <tscherler> - x2 plugin should provide xdocs2x2
> > > convertion
> > > Sep 19 11:19:17 <tscherler> - views should work with x2 input
> > > Sep 19 11:21:15 <tscherler> - we need to write a x2 to xhtml plugin
> > > Sep 19 11:21:52 <tscherler> that should be basically a bunch of contracts
> > > Sep 19 11:22:19 <tscherler> roadmap:
> > > Sep 19 11:22:31 <tscherler> 1) create new branch
> > > Sep 19 11:22:48 <tscherler> 2) move view stuff and x2 stuff into core
> > > Sep 19 11:23:10 <tscherler> 3) resolving by both only allowed through lm
> > > Sep 19 11:23:37 <tscherler> 4) create xdocs2x2 plugin
> > > Sep 19 11:24:10 <tscherler> 5) create x2 to xhtml plugin
> > > Sep 19 11:24:41 <tscherler> in this branch all skins are removed
> > > Sep 19 11:24:52 <tscherler> only view is supported
> > > Sep 19 11:25:19 <tscherler> skin pipes are to be refactored to output
> > > xhtml2
> >
> > Hold on. That IRC discussion was extremely rushed at the end.
> > We did not make any decisions there. Someone was going to make
> > a proposal. Are you sure that a branch is the way to do this?
> > Branches tend to become islands of lone development, and when
> > they go on for too long, become hard to merge.
> >
> > How will this branch be merged? I see some confusing quick
> > comments in that IRC log, but no resolution.
> >
> > The thing that really frightens me is the comment
> > "in this branch all skins are removed". Perhaps that is
> > what is needed, but we must decide and not just an offhand
> > comment in an IRC log.
> >
> > What was wrong with Thorsten's proposal to cease work
> > on the old plugins and create new plugins?
> >
> > -David
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
...
>>We should do parallel development on the 0.8/0.9 releases and the
>>views/xhtml2 work (done in plugins, yes I changed my mind).
>
>
> What caused you to change your mind?
>
> You almost had me convinced that doing the work
> in a development branch was the way to go.
To be totally honest, I didn't want another big discussion about how.
Thorsten is getting on with it as a plugin, thinking of his past (valid)
comments about too much discussion I am dropping it. If Thorsten wants
to move to a branch I will support that too.
If I find the time to get involved I may pick up the argument again, but
until then I'm happy to watch.
>>We keep trunk stable up until the 1.0-dev work. At this point we move
>>have a stable branch and a trunk for integration of views into core.
>>This is likely to end up in an unstable trunk for a time.
>
>
> Sorry, i cannot parse that paragraph.
> Did you mean to say "until the 0.10-dev work"?
Stable = "useable without having to jump through hoops"
However, you can completely disregard that paragraph - it is as good as
nonsense ;-)
Ross
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Ferdinand Soethe wrote:
> >Ross Gardler wrote:
> >
> >>>Are you gonna suggest the new release or should I?
> >
> >>http://marc.theaimsgroup.com/?l=forrest-dev&m=111986901417286&w=2
> >
> >Sorry, I was a bit terse.
> >
> >What I meant to say is exactly along the lines that Ross quoted here
> >(thanks, I'll add the title of Mc. Quickfind :-)).
> >
> >In other words: Now that we are back to a working trunk, let's start
> >working on 0.8 M1 with the locationmap as the only feature.
>
> We've done quite a bit of design work since that mail was written.
> Here's what I propose now (almost the same, but considering what has
> been said regarding the XHTML2 move):
>
> 0.8 - refactored sitemaps to utilise locationmap
> 0.9 - core as a plugin framework (all input/output code to plugins)
> 0.10 - views integration (which incorporate the move to XHTML2 subset)
> 1.0 - a big tidy up of JIRA issues
>
> I see the 0.8 and 0.9 releases as being fairly rapid. They are not huge
> jobs.
I like the idea of releasing in stages,
rather than a huge bang with many new or
changed functionality.
> It is the 0.10 work that will take lots of time (at least I
> believe so).
And then perhaps 0.11, 0.12 for bugfixing.
We need to be sure that 1.0 is robust.
> We should do parallel development on the 0.8/0.9 releases and the
> views/xhtml2 work (done in plugins, yes I changed my mind).
What caused you to change your mind?
You almost had me convinced that doing the work
in a development branch was the way to go.
> We keep trunk stable up until the 1.0-dev work. At this point we move
> have a stable branch and a trunk for integration of views into core.
> This is likely to end up in an unstable trunk for a time.
Sorry, i cannot parse that paragraph.
Did you mean to say "until the 0.10-dev work"?
Also i got confused about which bit is "stable"
and what stable means.
-David
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
I agree with everything you say re release early, release often (I have
a mail in my drafts folder I will send in a moment, I wanted to hear a
couple of other opinions before sending it).
> Btw: Please also re-consider Tim's excellent mail about doing the
> refactoring in smaller steps (Re: What does "XHTML2 as an
> internal document format" mean?)
Please read the IRC logs in which we discussed the implications of the
XHTML2 move and its interaction with views. Also see the mails leading
up to that discussion.
Conclusion of those present in the IRC session: It simply is not
sensible to do it in any smaller parts than those outlined at the end of
the session and being actioned right now by Thorsten.
Ross
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Ferdinand Soethe" <fe...@apache.org>
To: <de...@forrest.apache.org>
Sent: Saturday, October 01, 2005 11:55 AM
Subject: Re: A 0.8 release? (was Re: [Proposal] rollback)
| What is different about a feature development in a branch
| that I (for lack of time or interest) _choose_ not to look at before
| it is proposed for integration and a concurrent development of several
| features (current situation) that a significant number of committers
| cannot follow anymore because they simple get lost in the complexity
| of several things happening at the same time.
|
| Please do realize that other people do not have your level of
| understanding of Forrest so carrying on at the level of
| complexity you will simply loose their input. And that in my view is
| no longer a matter of choice of their part so I'd clearly prefer the
| first way.
|
| --
| Ferdinand Soethe
The above statements may apply to me, I am trying so hard
to keep up and yet still I do not understand all that is
going on. I get to a stage where I get something working and
then it is outdated and I have to play catch up again.
With the recent influx of changes, I feel I am right back at the
beginning when I joined this list a few months ago. I have had
to step back and watch for these last two weeks whilst things
settle down and direction gets found.
I am still wanting to help and do my bit, but again I am lost
as to what to do and where to do it. I do not have a
particular itch, I have a general itch, to help this project in
some way that the project will find useful. I think I will
continue to watch & learn for a few more days until I
find my opening again.
Apologies for being quiet in the meantime.
Gav...
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.9/116 - Release Date: 30/09/2005
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by Ferdinand Soethe <fe...@apache.org>.
Thorsten Scherler wrote:
>> This was confirmed in response to my recent suggestions to create all
>> new features in separate branches that can be integrated (and
>> released) as soon as they are stable.
> Merging different branches that are have to go to the core are *not*
> possible, merging will be nearly impossible (too many possible
> conflicts).
So why was this decided in the first place? Is it really impossible or
does it just require a different approach?
> Besides the danger of:
> El jue, 29-09-2005 a las 10:46 +1000, David Crossley escribió:
>> Branches tend to become islands of lone development, ...
Hmm ... This point was made before and I didn't object. Now I do:
What is different about a feature development in a branch
that I (for lack of time or interest) _choose_ not to look at before
it is proposed for integration and a concurrent development of several
features (current situation) that a significant number of committers
cannot follow anymore because they simple get lost in the complexity
of several things happening at the same time.
Please do realize that other people do not have your level of
understanding of Forrest so carrying on at the level of
complexity you will simply loose their input. And that in my view is
no longer a matter of choice of their part so I'd clearly prefer the
first way.
--
Ferdinand Soethe
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by Thorsten Scherler <th...@apache.org>.
El vie, 30-09-2005 a las 16:40 +0200, Ferdinand Soethe escribió:
...
> This was confirmed in response to my recent suggestions to create all
> new features in separate branches that can be integrated (and
> released) as soon as they are stable.
Merging different branches that are have to go to the core are *not*
possible, merging will be nearly impossible (too many possible
conflicts).
Besides the danger of:
El jue, 29-09-2005 a las 10:46 +1000, David Crossley escribió:
> Branches tend to become islands of lone development, ...
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by Ferdinand Soethe <fe...@apache.org>.
Thorsten Scherler wrote:
> Why do we want to release 0.8, now?
> I thought we said we need to refactor the whole lot but now we want
> again release partial work? We have ongoing discussions about opening
> new branches, doing the work in plugins, ...
We already have an agreement to do small releases more frequently.
This was confirmed in response to my recent suggestions to create all
new features in separate branches that can be integrated (and
released) as soon as they are stable.
Time to start doing this even though some new featured have not yet
been developed in branches (unfortunately).
Re: confusion
My personal reason for suggesting this release now is that I find the
parallel development of several features extremely hard to
follow, understand and participate in.
I'd much rather have a locationmap release on stable ground where I
can look at it, understand and document it, then move to the next new
feature.
Btw: Please also re-consider Tim's excellent mail about doing the
refactoring in smaller steps (Re: What does "XHTML2 as an
internal document format" mean?)
--
Ferdinand Soethe
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
>
> Why do we want to release 0.8, now?
One reason is that we agreed a while ago that
we should release more often. We also have an
improved Cocoon underneath. Features are easier
for users to grasp in small stages.
> I thought we said we need to refactor the whole lot but now we want
> again release partial work? We have ongoing discussions about opening
> new branches, doing the work in plugins, ...
Ongoing because it is obviously not decided how to
approach the work. Does it really matter that we
release partial work. It is clearly labelled as
being in development.
Sure we all want views/xhtml ready and released
ASAP, but the reality is that this will take time.
> Sorry, but it is starting to get real confusing.
>
> We need a final decision backup with a vote.
If we talk through the issues then we will have
a solid understanding of the best way to go
and a vote would be unnecessary.
If we do decide to make a 0.8 release now, then
we would need to take some time to improve the
current views documentation to emphasise that
if people want to work with "views" then they
need to not use the release code but jump into
the "0.x-dev" version.
-David
> -1 to release anything right now!
>
> salu2
> --
> thorsten
>
> "Together we stand, divided we fall!"
> Hey you (Pink Floyd)
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> Ross Gardler escribi??:
> > Thorsten Scherler wrote:
> > > Why do we want to release 0.8, now?
> >
> > release early, release often. This was discussed and agreed a month or
> > so ago.
>
> +1
>
> e.g. views reached their first stable version as prototype. Everything
> that is coming now make them again highly unstable (that is the reason
> why created the two new plugins). Now we can release them as first
> alternative to skins and state officially that the 0.8 release will be
> the last release that we recommend using skins.
Thanks. You now found the way forward.
> [ snip ]
> Being even more devils advocate let me ask if we want to release 08 as:
> >>0.8 - refactored sitemaps to utilise locationmap
> who is going to do this work?
Someone will. At least Ross, Ferdinand, and i are keen.
I will also help with documentation about project
codename "views".
-David
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El vie, 30-09-2005 a las 17:08 +0100, Ross Gardler escribió:
>
>>Thorsten Scherler wrote:
>>
>>>Why do we want to release 0.8, now?
>>
>>release early, release often. This was discussed and agreed a month or
>>so ago.
>
>
> +1
...
>>Besides, the locationmap is, in itself, a very powerful tool that makes
>>it possible for Forrest to be used for the apache site-build proposal
>>(which is gathering pace again). see
>>http://people.apache.org/~rgardler/site-build/summary.html
>
>
> totally agree. but being devils advocate and seeing:
> http://svn.apache.org/viewcvs.cgi/forrest/trunk/main/webapp/locationmap.xml?view=markup
> makes me ask what do we want to release?
See below, with respect to the work that needs doing before a release.
> Being even more devils advocate let me ask if we want to release 08 as:
>
>>>0.8 - refactored sitemaps to utilise locationmap
>
> who is going to do this work?
See below, with respect to the work that needs doing before a release.
>>The only harm I see is a very long development schedule to the next
>>release which will hold up the release of the locationmap, which in turn
>>will hold up the release/development of some important (to me only?)
>>plugins (e.g. Daisy, Lenya, Amazon ECS) and attraction of users/devs to
>>Forrest (through Apache site-build)
>
>
> Totally agree but we really have not put too much work in refactoring
> the *whole* sitemaps to lm.
See below, with respect to the work that needs doing before a release.
>>>-1 to release anything right now!
>>
>>It's not right now it's once the sitemaps are refactored (which I will
>>do in the coming weeks).
>
>
> Actually that is the point, why you only? Refactoring the sitemaps can
> be done by *all* committers. There is no secrets to it.
That is correct. However, this is Open Source. It is done by those wo
have the itch. I have the itch, I will do it (and lets not forget that
Tim has done lots of preparatory work for me/us).
>>This is a *much* smaller job than the
>>XHTML2/views integration. Making core a plugin framework (0.9) paves the
>>way for integration of the views plugins (0.10) by cleaning up core even
>>more.
>
>
> Actually I will be able to in-cooperate views as soon the jxpath-1.2
> problem is solved. Thanks to Antonio, David et. al. that spend a lot of
> time solving the problem I think latest in 0.9 views are in the core
> and will make skins obsolete (can be earlier if we solve the
> linkrewritter/jxpath bug). I am right now as well looking into blocks
> and trying to make views a cocoon block.
Yes, my proposal is only an outline, things can come in a different
order if that, is what happens.
>>Does a 0.8 release prevent you from continuing work on the views stuff?
>>Is there really a need for a -1?
>
>
> A release can be done when I see the lm stuff. *Or* we refocus the
> release.
See above about the work still needing to be done and who has th time +
itch to do it.
> Like you stated they are other components that actually are
> justifying a release and we do not have to refactor all pipes for it.
True.
Ross
Re: devs do what we can (Was: A 0.8 release? (was Re: [Proposal] rollback))
Posted by David Crossley <cr...@apache.org>.
You are correct. People need to do the work if they
have the energy to initiate a release. Other people
will follow and help. Same in every open source project.
And no-one needs to feel guilty for not helping.
When it happens it happens. If not then we will continue
on until the momentum gains.
-David
Ross Gardler wrote:
> I am making no cuts and no inline comments, it would be a crime to mess
> with the message Diwaker is sending here. Thank you, Diwaker, you are
> right on target.
>
> Ross
>
> ----------------------------------------
> Diwaker Gupta wrote:
> >>No offense to anyone but if somebody wants to release 0.8 as -
> >>refactored sitemaps to utilise locationmap, then we (or better this
> >>somebody) has to put some more work into it. It cannot be that we expect
> >>from the usual suspects that they now as well put more work into that
> >>part of forrest.
> >>
> >>Actually that is the point, why you only? Refactoring the sitemaps can
> >>be done by *all* committers. There is no secrets to it.
> >
> >I think this remark carries some negative connotation that bothers me.
> >I will try to be concise and objective in my statements so as to avoid
> >any confusion.
> >
> >I started using Forrest because it was a cool tool that fit my needs
> >perfectly. In using it I found some things that I needed that weren't
> >there and were not hard to fix, so I sent in the occasional patch. I
> >like living on the bleeding edge of cool software, so when views were
> >out I was quick to put them to test and I really liked the concept.
> >
> >With every project, there comes a time when the project sort of comes
> >of age. I think Forrest is nearing that time now. There are a lot of
> >ideas, discussions, community building up -- Forrest is trying to
> >define itself, which is fantastic. But like all good things, it will
> >take its time. I try to follow the discussions as and when I can, and
> >put in my thoughts if I have something to add. Otherwise I'm happy to
> >watch.
> >
> >I don't use Forrest at work. I don't get money out of Forrest related
> >work. For me, the only interest in Forrest is personal. I try and
> >contribute when I have the time and motivation, and it doesn't help if
> >I feel there is some 'pressure' or 'expection' when I don't.
> >
> >Like Ross said, this is open source. If someone has a itch, they
> >scratch it. At the same time however, for any good and large open
> >source project to succeed it usually takes more than a passing
> >interest and commitment on the part of atleast some of the developers.
> >Typically (there are always exceptions) people who have a more
> >concrete interest (work related, for instance) in the product will be
> >the stewards of large changes and I think that works out well.
> >
> >While I really appreciate all the hard work everyone puts into
> >Forrest, getting negative vibes about the "other" developers not
> >putting in enough effort doesn't help the project or the community.
> >People do what they want to do, and the community recognizes them for
> >it. If I am unable to contribute as much as the next developer, I
> >don't want to be judged for it, nor want other developers to feel bad
> >about it.
> >
> >I have great respect for the work that people are doing here, but I
> >feel bad if they think of themselves as the "usual suspects".
> >
> >Just my 2c.
> >--
> >Web/Blog/Gallery: floatingsun.net
> >
> >
devs do what we can (Was: A 0.8 release? (was Re: [Proposal] rollback))
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> I am making no cuts and no inline comments, it would be a crime to mess
> with the message Diwaker is sending here. Thank you, Diwaker, you are
> right on target.
>
> Ross
>
> ----------------------------------------
> Diwaker Gupta wrote:
> >>No offense to anyone but if somebody wants to release 0.8 as -
> >>refactored sitemaps to utilise locationmap, then we (or better this
> >>somebody) has to put some more work into it. It cannot be that we expect
> >>from the usual suspects that they now as well put more work into that
> >>part of forrest.
> >>
> >>Actually that is the point, why you only? Refactoring the sitemaps can
> >>be done by *all* committers. There is no secrets to it.
> >
> >I think this remark carries some negative connotation that bothers me.
> >I will try to be concise and objective in my statements so as to avoid
> >any confusion.
> >
> >I started using Forrest because it was a cool tool that fit my needs
> >perfectly. In using it I found some things that I needed that weren't
> >there and were not hard to fix, so I sent in the occasional patch. I
> >like living on the bleeding edge of cool software, so when views were
> >out I was quick to put them to test and I really liked the concept.
> >
> >With every project, there comes a time when the project sort of comes
> >of age. I think Forrest is nearing that time now. There are a lot of
> >ideas, discussions, community building up -- Forrest is trying to
> >define itself, which is fantastic. But like all good things, it will
> >take its time. I try to follow the discussions as and when I can, and
> >put in my thoughts if I have something to add. Otherwise I'm happy to
> >watch.
> >
> >I don't use Forrest at work. I don't get money out of Forrest related
> >work. For me, the only interest in Forrest is personal. I try and
> >contribute when I have the time and motivation, and it doesn't help if
> >I feel there is some 'pressure' or 'expection' when I don't.
> >
> >Like Ross said, this is open source. If someone has a itch, they
> >scratch it. At the same time however, for any good and large open
> >source project to succeed it usually takes more than a passing
> >interest and commitment on the part of atleast some of the developers.
> >Typically (there are always exceptions) people who have a more
> >concrete interest (work related, for instance) in the product will be
> >the stewards of large changes and I think that works out well.
> >
> >While I really appreciate all the hard work everyone puts into
> >Forrest, getting negative vibes about the "other" developers not
> >putting in enough effort doesn't help the project or the community.
> >People do what they want to do, and the community recognizes them for
> >it. If I am unable to contribute as much as the next developer, I
> >don't want to be judged for it, nor want other developers to feel bad
> >about it.
> >
> >I have great respect for the work that people are doing here, but I
> >feel bad if they think of themselves as the "usual suspects".
> >
> >Just my 2c.
> >--
> >Web/Blog/Gallery: floatingsun.net
> >
> >
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> I never tried to produce pressure! I only said (with other words then
> Ross) if it is your itch to release then scratch it by helping to do the
> work involved.
>
> BTW forrest is for me as well only hobby.
>
> It seems anything that I say is taken differently then I indented, I am
> quite tiered of this and will try not to get involved in any such
> discussions anymore. It is to frustrating.
You are reacting, please calm down. We all know
what you intended. We trust you.
Look at it with a different view.
The things that came out of that discussion are
perhaps things that needed to be said. You were
the catalyst. Thanks.
By the way its a pity that you didn't reply to this
in the other thread. I tried to move that discussion
to a new subject, and separate this from the reasons
for doing a 0.8 release. Anyway a note for the archives:
http://marc.theaimsgroup.com/?t=112813301300001
Re: devs do what we can
-David
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Thorsten Scherler wrote:
...
> BTW forrest is for me as well only hobby.
Same here.
> It seems anything that I say is taken differently then I indented, I am
> quite tiered of this and will try not to get involved in any such
> discussions anymore. It is to frustrating.
Same here.
PS: I have not followed the discussion, I only read mail snippet.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Thorsten Scherler" <th...@apache.org>
To: <de...@forrest.apache.org>
Sent: Saturday, October 01, 2005 7:23 PM
Subject: Re: A 0.8 release? (was Re: [Proposal] rollback)
|I never tried to produce pressure! I only said (with other words then
| Ross) if it is your itch to release then scratch it by helping to do the
| work involved.
|
| BTW forrest is for me as well only hobby.
|
| It seems anything that I say is taken differently then I indented, I am
| quite tiered of this and will try not to get involved in any such
| discussions anymore. It is to frustrating.
|
Thorsten,
Your discussions are quite invaluable and I personally took no offense
from your comments. These discussions are I think a requirement
to the success and continued forward momentum of this project.
Please don't stop now.
Gav...
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.9/116 - Release Date: 30/09/2005
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by Thorsten Scherler <th...@apache.org>.
I never tried to produce pressure! I only said (with other words then
Ross) if it is your itch to release then scratch it by helping to do the
work involved.
BTW forrest is for me as well only hobby.
It seems anything that I say is taken differently then I indented, I am
quite tiered of this and will try not to get involved in any such
discussions anymore. It is to frustrating.
salu2
El sáb, 01-10-2005 a las 00:02 +0100, Ross Gardler escribió:
> I am making no cuts and no inline comments, it would be a crime to mess
> with the message Diwaker is sending here. Thank you, Diwaker, you are
> right on target.
>
> Ross
>
> Diwaker Gupta wrote:
> >>No offense to anyone but if somebody wants to release 0.8 as -
> >>refactored sitemaps to utilise locationmap, then we (or better this
> >>somebody) has to put some more work into it. It cannot be that we expect
> >>from the usual suspects that they now as well put more work into that
> >>part of forrest.
> >>
> >>Actually that is the point, why you only? Refactoring the sitemaps can
> >>be done by *all* committers. There is no secrets to it.
> >
> >
> > I think this remark carries some negative connotation that bothers me.
> > I will try to be concise and objective in my statements so as to avoid
> > any confusion.
> >
> > I started using Forrest because it was a cool tool that fit my needs
> > perfectly. In using it I found some things that I needed that weren't
> > there and were not hard to fix, so I sent in the occasional patch. I
> > like living on the bleeding edge of cool software, so when views were
> > out I was quick to put them to test and I really liked the concept.
> >
> > With every project, there comes a time when the project sort of comes
> > of age. I think Forrest is nearing that time now. There are a lot of
> > ideas, discussions, community building up -- Forrest is trying to
> > define itself, which is fantastic. But like all good things, it will
> > take its time. I try to follow the discussions as and when I can, and
> > put in my thoughts if I have something to add. Otherwise I'm happy to
> > watch.
> >
> > I don't use Forrest at work. I don't get money out of Forrest related
> > work. For me, the only interest in Forrest is personal. I try and
> > contribute when I have the time and motivation, and it doesn't help if
> > I feel there is some 'pressure' or 'expection' when I don't.
> >
> > Like Ross said, this is open source. If someone has a itch, they
> > scratch it. At the same time however, for any good and large open
> > source project to succeed it usually takes more than a passing
> > interest and commitment on the part of atleast some of the developers.
> > Typically (there are always exceptions) people who have a more
> > concrete interest (work related, for instance) in the product will be
> > the stewards of large changes and I think that works out well.
> >
> > While I really appreciate all the hard work everyone puts into
> > Forrest, getting negative vibes about the "other" developers not
> > putting in enough effort doesn't help the project or the community.
> > People do what they want to do, and the community recognizes them for
> > it. If I am unable to contribute as much as the next developer, I
> > don't want to be judged for it, nor want other developers to feel bad
> > about it.
> >
> > I have great respect for the work that people are doing here, but I
> > feel bad if they think of themselves as the "usual suspects".
> >
> > Just my 2c.
> > --
> > Web/Blog/Gallery: floatingsun.net
> >
> >
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by Ross Gardler <rg...@apache.org>.
I am making no cuts and no inline comments, it would be a crime to mess
with the message Diwaker is sending here. Thank you, Diwaker, you are
right on target.
Ross
Diwaker Gupta wrote:
>>No offense to anyone but if somebody wants to release 0.8 as -
>>refactored sitemaps to utilise locationmap, then we (or better this
>>somebody) has to put some more work into it. It cannot be that we expect
>>from the usual suspects that they now as well put more work into that
>>part of forrest.
>>
>>Actually that is the point, why you only? Refactoring the sitemaps can
>>be done by *all* committers. There is no secrets to it.
>
>
> I think this remark carries some negative connotation that bothers me.
> I will try to be concise and objective in my statements so as to avoid
> any confusion.
>
> I started using Forrest because it was a cool tool that fit my needs
> perfectly. In using it I found some things that I needed that weren't
> there and were not hard to fix, so I sent in the occasional patch. I
> like living on the bleeding edge of cool software, so when views were
> out I was quick to put them to test and I really liked the concept.
>
> With every project, there comes a time when the project sort of comes
> of age. I think Forrest is nearing that time now. There are a lot of
> ideas, discussions, community building up -- Forrest is trying to
> define itself, which is fantastic. But like all good things, it will
> take its time. I try to follow the discussions as and when I can, and
> put in my thoughts if I have something to add. Otherwise I'm happy to
> watch.
>
> I don't use Forrest at work. I don't get money out of Forrest related
> work. For me, the only interest in Forrest is personal. I try and
> contribute when I have the time and motivation, and it doesn't help if
> I feel there is some 'pressure' or 'expection' when I don't.
>
> Like Ross said, this is open source. If someone has a itch, they
> scratch it. At the same time however, for any good and large open
> source project to succeed it usually takes more than a passing
> interest and commitment on the part of atleast some of the developers.
> Typically (there are always exceptions) people who have a more
> concrete interest (work related, for instance) in the product will be
> the stewards of large changes and I think that works out well.
>
> While I really appreciate all the hard work everyone puts into
> Forrest, getting negative vibes about the "other" developers not
> putting in enough effort doesn't help the project or the community.
> People do what they want to do, and the community recognizes them for
> it. If I am unable to contribute as much as the next developer, I
> don't want to be judged for it, nor want other developers to feel bad
> about it.
>
> I have great respect for the work that people are doing here, but I
> feel bad if they think of themselves as the "usual suspects".
>
> Just my 2c.
> --
> Web/Blog/Gallery: floatingsun.net
>
>
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by Diwaker Gupta <di...@apache.org>.
> No offense to anyone but if somebody wants to release 0.8 as -
> refactored sitemaps to utilise locationmap, then we (or better this
> somebody) has to put some more work into it. It cannot be that we expect
> from the usual suspects that they now as well put more work into that
> part of forrest.
>
> Actually that is the point, why you only? Refactoring the sitemaps can
> be done by *all* committers. There is no secrets to it.
I think this remark carries some negative connotation that bothers me.
I will try to be concise and objective in my statements so as to avoid
any confusion.
I started using Forrest because it was a cool tool that fit my needs
perfectly. In using it I found some things that I needed that weren't
there and were not hard to fix, so I sent in the occasional patch. I
like living on the bleeding edge of cool software, so when views were
out I was quick to put them to test and I really liked the concept.
With every project, there comes a time when the project sort of comes
of age. I think Forrest is nearing that time now. There are a lot of
ideas, discussions, community building up -- Forrest is trying to
define itself, which is fantastic. But like all good things, it will
take its time. I try to follow the discussions as and when I can, and
put in my thoughts if I have something to add. Otherwise I'm happy to
watch.
I don't use Forrest at work. I don't get money out of Forrest related
work. For me, the only interest in Forrest is personal. I try and
contribute when I have the time and motivation, and it doesn't help if
I feel there is some 'pressure' or 'expection' when I don't.
Like Ross said, this is open source. If someone has a itch, they
scratch it. At the same time however, for any good and large open
source project to succeed it usually takes more than a passing
interest and commitment on the part of atleast some of the developers.
Typically (there are always exceptions) people who have a more
concrete interest (work related, for instance) in the product will be
the stewards of large changes and I think that works out well.
While I really appreciate all the hard work everyone puts into
Forrest, getting negative vibes about the "other" developers not
putting in enough effort doesn't help the project or the community.
People do what they want to do, and the community recognizes them for
it. If I am unable to contribute as much as the next developer, I
don't want to be judged for it, nor want other developers to feel bad
about it.
I have great respect for the work that people are doing here, but I
feel bad if they think of themselves as the "usual suspects".
Just my 2c.
--
Web/Blog/Gallery: floatingsun.net
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by Thorsten Scherler <th...@apache.org>.
El vie, 30-09-2005 a las 17:08 +0100, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > Why do we want to release 0.8, now?
>
> release early, release often. This was discussed and agreed a month or
> so ago.
+1
e.g. views reached their first stable version as prototype. Everything
that is coming now make them again highly unstable (that is the reason
why created the two new plugins). Now we can release them as first
alternative to skins and state officially that the 0.8 release will be
the last release that we recommend using skins.
> > I thought we said we need to refactor the whole lot but now we want
> > again release partial work?
>
> Refactor the whole lot for a 1.0 release, yes, but there is nothing
> wrong with doing it in stages (in fact it is a good idea to do so,
> release early, release often)
Agree
>
> Besides, the locationmap is, in itself, a very powerful tool that makes
> it possible for Forrest to be used for the apache site-build proposal
> (which is gathering pace again). see
> http://people.apache.org/~rgardler/site-build/summary.html
totally agree. but being devils advocate and seeing:
http://svn.apache.org/viewcvs.cgi/forrest/trunk/main/webapp/locationmap.xml?view=markup
makes me ask what do we want to release?
Being even more devils advocate let me ask if we want to release 08 as:
>>0.8 - refactored sitemaps to utilise locationmap
who is going to do this work?
No offense to anyone but if somebody wants to release 0.8 as -
refactored sitemaps to utilise locationmap, then we (or better this
somebody) has to put some more work into it. It cannot be that we expect
from the usual suspects that they now as well put more work into that
part of forrest.
> > We have ongoing discussions about opening
> > new branches, doing the work in plugins, ...
> >
> > We need a final decision backup with a vote.
>
> Yes, that concerns me too, that is why I changed my mind about
> branch/plugins decision for the XHTML2 work. You are *doing* it in a
> plugin. My concern was only that it was you that suggested a branch on
> IRC. To be honest I don't care, as long as it gets done and since you
> are *doing* it I don't want to stand in your way - no need for
> discussion or vote unless someone sees harm.
Understood and thx. The rollback was necessary to let user and devs use
views again.
> The only harm I see is a very long development schedule to the next
> release which will hold up the release of the locationmap, which in turn
> will hold up the release/development of some important (to me only?)
> plugins (e.g. Daisy, Lenya, Amazon ECS) and attraction of users/devs to
> Forrest (through Apache site-build)
Totally agree but we really have not put too much work in refactoring
the *whole* sitemaps to lm.
> > -1 to release anything right now!
>
> It's not right now it's once the sitemaps are refactored (which I will
> do in the coming weeks).
Actually that is the point, why you only? Refactoring the sitemaps can
be done by *all* committers. There is no secrets to it.
> This is a *much* smaller job than the
> XHTML2/views integration. Making core a plugin framework (0.9) paves the
> way for integration of the views plugins (0.10) by cleaning up core even
> more.
Actually I will be able to in-cooperate views as soon the jxpath-1.2
problem is solved. Thanks to Antonio, David et. al. that spend a lot of
time solving the problem I think latest in 0.9 views are in the core
and will make skins obsolete (can be earlier if we solve the
linkrewritter/jxpath bug). I am right now as well looking into blocks
and trying to make views a cocoon block.
> Does a 0.8 release prevent you from continuing work on the views stuff?
> Is there really a need for a -1?
A release can be done when I see the lm stuff. *Or* we refocus the
release. Like you stated they are other components that actually are
justifying a release and we do not have to refactor all pipes for it.
> ---
>
> I did miss something out in the schedule though:
>
> >>0.8 - refactored sitemaps to utilise locationmap
> >>0.9 - core as a plugin framework (all input/output code to plugins)
> >>0.10 - views integration (which incorporate the move to XHTML2 subset)
>
> 0.11 - forrest as a Cocoon block (includes new config system)
That would be nice.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> Why do we want to release 0.8, now?
release early, release often. This was discussed and agreed a month or
so ago.
> I thought we said we need to refactor the whole lot but now we want
> again release partial work?
Refactor the whole lot for a 1.0 release, yes, but there is nothing
wrong with doing it in stages (in fact it is a good idea to do so,
release early, release often)
Besides, the locationmap is, in itself, a very powerful tool that makes
it possible for Forrest to be used for the apache site-build proposal
(which is gathering pace again). see
http://people.apache.org/~rgardler/site-build/summary.html
> We have ongoing discussions about opening
> new branches, doing the work in plugins, ...
>
> We need a final decision backup with a vote.
Yes, that concerns me too, that is why I changed my mind about
branch/plugins decision for the XHTML2 work. You are *doing* it in a
plugin. My concern was only that it was you that suggested a branch on
IRC. To be honest I don't care, as long as it gets done and since you
are *doing* it I don't want to stand in your way - no need for
discussion or vote unless someone sees harm.
The only harm I see is a very long development schedule to the next
release which will hold up the release of the locationmap, which in turn
will hold up the release/development of some important (to me only?)
plugins (e.g. Daisy, Lenya, Amazon ECS) and attraction of users/devs to
Forrest (through Apache site-build)
> -1 to release anything right now!
It's not right now it's once the sitemaps are refactored (which I will
do in the coming weeks). This is a *much* smaller job than the
XHTML2/views integration. Making core a plugin framework (0.9) paves the
way for integration of the views plugins (0.10) by cleaning up core even
more.
Does a 0.8 release prevent you from continuing work on the views stuff?
Is there really a need for a -1?
---
I did miss something out in the schedule though:
>>0.8 - refactored sitemaps to utilise locationmap
>>0.9 - core as a plugin framework (all input/output code to plugins)
>>0.10 - views integration (which incorporate the move to XHTML2 subset)
0.11 - forrest as a Cocoon block (includes new config system)
>>1.0 - a big tidy up of JIRA issues
>>
>>I see the 0.8 and 0.9 releases as being fairly rapid. They are not huge
>>jobs. It is the 0.10 work that will take lots of time (at least I
>>believe so).
>>
>>We should do parallel development on the 0.8/0.9 releases and the
>>views/xhtml2 work (done in plugins, yes I changed my mind).
>>
>>We keep trunk stable up until the 1.0-dev work. At this point we move
>>have a stable branch and a trunk for integration of views into core.
>>This is likely to end up in an unstable trunk for a time.
>>
>>Ross
Re: A 0.8 release? (was Re: [Proposal] rollback)
Posted by Thorsten Scherler <th...@apache.org>.
Why do we want to release 0.8, now?
I thought we said we need to refactor the whole lot but now we want
again release partial work? We have ongoing discussions about opening
new branches, doing the work in plugins, ...
Sorry, but it is starting to get real confusing.
We need a final decision backup with a vote.
-1 to release anything right now!
salu2
El vie, 30-09-2005 a las 12:18 +0100, Ross Gardler escribió:
> Ferdinand Soethe wrote:
> > Ross Gardler wrote:
> >
> >
> >>>Are you gonna suggest the new release or should I?
> >
> >
> >>http://marc.theaimsgroup.com/?l=forrest-dev&m=111986901417286&w=2
> >
> >
> > Sorry, I was a bit terse.
> >
> > What I meant to say is exactly along the lines that Ross quoted here
> > (thanks, I'll add the title of Mc. Quickfind :-)).
> >
> > In other words: Now that we are back to a working trunk, let's start
> > working on 0.8 M1 with the locationmap as the only feature.
>
> We've done quite a bit of design work since that mail was written.
> Here's what I propose now (almost the same, but considering what has
> been said regarding the XHTML2 move):
>
> 0.8 - refactored sitemaps to utilise locationmap
> 0.9 - core as a plugin framework (all input/output code to plugins)
> 0.10 - views integration (which incorporate the move to XHTML2 subset)
> 1.0 - a big tidy up of JIRA issues
>
> I see the 0.8 and 0.9 releases as being fairly rapid. They are not huge
> jobs. It is the 0.10 work that will take lots of time (at least I
> believe so).
>
> We should do parallel development on the 0.8/0.9 releases and the
> views/xhtml2 work (done in plugins, yes I changed my mind).
>
> We keep trunk stable up until the 1.0-dev work. At this point we move
> have a stable branch and a trunk for integration of views into core.
> This is likely to end up in an unstable trunk for a time.
>
> Ross
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
A 0.8 release? (was Re: [Proposal] rollback)
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> Ross Gardler wrote:
>
>
>>>Are you gonna suggest the new release or should I?
>
>
>>http://marc.theaimsgroup.com/?l=forrest-dev&m=111986901417286&w=2
>
>
> Sorry, I was a bit terse.
>
> What I meant to say is exactly along the lines that Ross quoted here
> (thanks, I'll add the title of Mc. Quickfind :-)).
>
> In other words: Now that we are back to a working trunk, let's start
> working on 0.8 M1 with the locationmap as the only feature.
We've done quite a bit of design work since that mail was written.
Here's what I propose now (almost the same, but considering what has
been said regarding the XHTML2 move):
0.8 - refactored sitemaps to utilise locationmap
0.9 - core as a plugin framework (all input/output code to plugins)
0.10 - views integration (which incorporate the move to XHTML2 subset)
1.0 - a big tidy up of JIRA issues
I see the 0.8 and 0.9 releases as being fairly rapid. They are not huge
jobs. It is the 0.10 work that will take lots of time (at least I
believe so).
We should do parallel development on the 0.8/0.9 releases and the
views/xhtml2 work (done in plugins, yes I changed my mind).
We keep trunk stable up until the 1.0-dev work. At this point we move
have a stable branch and a trunk for integration of views into core.
This is likely to end up in an unstable trunk for a time.
Ross
Re: [Proposal] rollback
Posted by Ferdinand Soethe <fe...@apache.org>.
Ross Gardler wrote:
>> Are you gonna suggest the new release or should I?
> http://marc.theaimsgroup.com/?l=forrest-dev&m=111986901417286&w=2
Sorry, I was a bit terse.
What I meant to say is exactly along the lines that Ross quoted here
(thanks, I'll add the title of Mc. Quickfind :-)).
In other words: Now that we are back to a working trunk, let's start
working on 0.8 M1 with the locationmap as the only feature.
--
Ferdinand Soethe
Re: [Proposal] rollback
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
>
>
>
>
>
> Thorsten Scherler wrote:
>
>
>>I reverted the plugins and keep working on the new plugins till we
>>settle this discussion about branching or not.
>
>
>>That makes user and dev using views like they were used to do before.
>
>
> Are you gonna suggest the new release or should I?
http://marc.theaimsgroup.com/?l=forrest-dev&m=111986901417286&w=2
Ross
Re: [Proposal] rollback
Posted by Ferdinand Soethe <fe...@apache.org>.
Thorsten Scherler wrote:
> I reverted the plugins and keep working on the new plugins till we
> settle this discussion about branching or not.
> That makes user and dev using views like they were used to do before.
Are you gonna suggest the new release or should I?
--
Ferdinand Soethe
Re: [Proposal] rollback
Posted by Thorsten Scherler <th...@apache.org>.
I reverted the plugins and keep working on the new plugins till we
settle this discussion about branching or not.
That makes user and dev using views like they were used to do before.
salu2
El jue, 29-09-2005 a las 10:46 +1000, David Crossley escribió:
> Ross Gardler wrote:
> > Diwaker Gupta wrote:
> > >Thorsten Scherler wrote:
> > >
> > >>>Added two new plugins for
> > >>>refactoring views into the core:
> > >>>- structurer
> > >>>- themes
> > >>>
> > >>>Recent changes to views with using jxtg as core component
> > >>>made the old view plugins unusable (FOR-675)
> > >>>which can not longer stay like this.
> > >>>
> > >>>I recommend to rollback:
> > >>>- org.apache.forrest.plugin.internal.view
> > >>>- org.apache.forrest.plugin.output.viewHelper.xhtml
> > >>>to revision -r280939 and then commit them back as views head.
> > >
> > >Why can't we just roll back trunk to a stable version, and move the
> > >views/xhtml2 work to a new branch? I think thats much neater, and easier
> > >both on devs and users alike. People can hack away on the views/xhtml2
> > >branch without having to worry about breaking trunk for someone.
> >
> > +1
> >
> > In fact this is exactly what we agreed in the IRC session:
> >
> > Sep 19 11:17:31 <tscherler> - we should get the xhtml2 and view internal
> > together
> > Sep 19 11:18:03 <tscherler> - xhtml2 should be merged into the internal
> > views stuff, simply replace the docuemnt2html part
> > Sep 19 11:18:42 <tscherler> - x2 plugin should provide xdocs2x2
> > convertion
> > Sep 19 11:19:17 <tscherler> - views should work with x2 input
> > Sep 19 11:21:15 <tscherler> - we need to write a x2 to xhtml plugin
> > Sep 19 11:21:52 <tscherler> that should be basically a bunch of contracts
> > Sep 19 11:22:19 <tscherler> roadmap:
> > Sep 19 11:22:31 <tscherler> 1) create new branch
> > Sep 19 11:22:48 <tscherler> 2) move view stuff and x2 stuff into core
> > Sep 19 11:23:10 <tscherler> 3) resolving by both only allowed through lm
> > Sep 19 11:23:37 <tscherler> 4) create xdocs2x2 plugin
> > Sep 19 11:24:10 <tscherler> 5) create x2 to xhtml plugin
> > Sep 19 11:24:41 <tscherler> in this branch all skins are removed
> > Sep 19 11:24:52 <tscherler> only view is supported
> > Sep 19 11:25:19 <tscherler> skin pipes are to be refactored to output
> > xhtml2
>
> Hold on. That IRC discussion was extremely rushed at the end.
> We did not make any decisions there. Someone was going to make
> a proposal. Are you sure that a branch is the way to do this?
> Branches tend to become islands of lone development, and when
> they go on for too long, become hard to merge.
>
> How will this branch be merged? I see some confusing quick
> comments in that IRC log, but no resolution.
>
> The thing that really frightens me is the comment
> "in this branch all skins are removed". Perhaps that is
> what is needed, but we must decide and not just an offhand
> comment in an IRC log.
>
> What was wrong with Thorsten's proposal to cease work
> on the old plugins and create new plugins?
>
> -David
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Starting a 1.0 development (Re: [Proposal] rollback)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >>Diwaker Gupta wrote:
> >>>Thorsten Scherler wrote:
> >>>
> >>>>>Added two new plugins for
> >>>>>refactoring views into the core:
> >>>>>- structurer
> >>>>>- themes
> >>>>>
> >>>>>Recent changes to views with using jxtg as core component
> >>>>>made the old view plugins unusable (FOR-675)
> >>>>>which can not longer stay like this.
> >>>>>
> >>>>>I recommend to rollback:
> >>>>>- org.apache.forrest.plugin.internal.view
> >>>>>- org.apache.forrest.plugin.output.viewHelper.xhtml
> >>>>>to revision -r280939 and then commit them back as views head.
> >>>
> >>>Why can't we just roll back trunk to a stable version, and move the
> >>>views/xhtml2 work to a new branch? I think thats much neater, and easier
> >>>both on devs and users alike. People can hack away on the views/xhtml2
> >>>branch without having to worry about breaking trunk for someone.
> >>
> >>+1
> >>
> >>In fact this is exactly what we agreed in the IRC session:
> >>
> >>Sep 19 11:17:31 <tscherler> - we should get the xhtml2 and view internal
> >>together
> >>Sep 19 11:18:03 <tscherler> - xhtml2 should be merged into the internal
> >>views stuff, simply replace the docuemnt2html part
> >>Sep 19 11:18:42 <tscherler> - x2 plugin should provide xdocs2x2
> >>convertion
> >>Sep 19 11:19:17 <tscherler> - views should work with x2 input
> >>Sep 19 11:21:15 <tscherler> - we need to write a x2 to xhtml plugin
> >>Sep 19 11:21:52 <tscherler> that should be basically a bunch of contracts
> >>Sep 19 11:22:19 <tscherler> roadmap:
> >>Sep 19 11:22:31 <tscherler> 1) create new branch
> >>Sep 19 11:22:48 <tscherler> 2) move view stuff and x2 stuff into core
> >>Sep 19 11:23:10 <tscherler> 3) resolving by both only allowed through lm
> >>Sep 19 11:23:37 <tscherler> 4) create xdocs2x2 plugin
> >>Sep 19 11:24:10 <tscherler> 5) create x2 to xhtml plugin
> >>Sep 19 11:24:41 <tscherler> in this branch all skins are removed
> >>Sep 19 11:24:52 <tscherler> only view is supported
> >>Sep 19 11:25:19 <tscherler> skin pipes are to be refactored to output
> >>xhtml2
> >
> >Hold on. That IRC discussion was extremely rushed at the end.
> >We did not make any decisions there. Someone was going to make
> >a proposal. Are you sure that a branch is the way to do this?
>
> Yes, you are right. Lets start discussing the proposal in the open.
>
> >Branches tend to become islands of lone development, and when
> >they go on for too long, become hard to merge.
>
> This work will touch pretty much *all* of Forrest. It will introduce:
>
> - XHTML2 - rewrite of core processing pipelines
> - Views - rewrite of core processing pipelines
> - Locationmap - rewrite of core processing pipelines
>
> So...
>
> >How will this branch be merged? I see some confusing quick
> >comments in that IRC log, but no resolution.
>
> We didn't foresee merging this branch, rather replacing the current trunk:
>
> Sep 19 11:32:23 <tscherler> that and is needed for an internal skin
> plugin
> Sep 19 11:32:29 <rgardler> David: after we merge this beast? -> I do
> not see us merging this branch, I see this as a compelte rewrite
> Sep 19 11:32:40 <rgardler> all the stripped out stuff goes in plugins
> Sep 19 11:32:54 <tscherler> +1
> Sep 19 11:32:55 <rgardler> we are lef with a really clean core that
> does nothing but the structurer part
> Sep 19 11:33:30 <crossley> radical. So we cease development on trunk?
> Sep 19 11:33:33 <rgardler> If you know Eclipse you'll understand the
> beuaty of this
> Sep 19 11:34:02 <rgardler> if not, think of Jedit - similar concept,
> Sep 19 11:34:12 <rgardler> JEdit does nothing but provide a text editor
> and a plugin frameowrk
> Sep 19 11:34:33 <tscherler> (02:33:47) crossley: radical. So we cease
> development on trunk?-> basically it should become a stable branch
> Sep 19 11:34:47 <tscherler> like cocoon-2.1.x
> Sep 19 11:34:51 <rgardler> Yes, make a 0.8 release and only do bug fixes
> Sep 19 11:35:49 <tscherler> that would not meet "usable trunk " approach
> but we can have 0.8 branch for that
> Sep 19 11:35:58 <tscherler> better 0.8.x
> Sep 19 11:36:27 <rgardler> I think we are in the mechanics now, that is
> easy to do onlist
>
> And so here we are onlist ;-)
Thanks, that was a productive way to bring out the
information for the discussion that we needed to have.
> >The thing that really frightens me is the comment
> >"in this branch all skins are removed". Perhaps that is
> >what is needed, but we must decide and not just an offhand
> >comment in an IRC log.
>
> Yes, you raised this issue onIRC too:
>
> Sep 19 11:28:57 <crossley> So the old "skins" still continue to
> function?
> Sep 19 11:29:11 <crossley> after we merge this beast?
> Sep 19 11:29:17 <tscherler> no
> Sep 19 11:29:26 <rgardler> We can make an internal plugin that provides
> backward compatability
> Sep 19 11:29:33 <tscherler> yes
> Sep 19 11:29:39 <rgardler> I think we need to do that otherwise users
> will not upgrade
> Sep 19 11:29:51 <tscherler> +1
> Sep 19 11:30:00 <crossley> rgardler: good but is that possible
> Sep 19 11:30:08 <tscherler> yes it isd
> Sep 19 11:30:22 <rgardler> Yes, at worst we simply take trunk and make
> it a plugin ;-)
> Sep 19 11:30:31 <tscherler> +1
>
> In other words, core will *not* have skin functionality. It will only be
> available in a (deprecated?) plugin.
Great, that makes a sigh of relief for the whole
community. If projects need to continue with skins
for a while then we can. Just that the Forrest project
will be putting all our effort into "views".
We need to document that approach for skins deprecation.
At least it is mentioned now here on list.
If no-one speaks up about that then we can take that
as a decision.
> >What was wrong with Thorsten's proposal to cease work
> >on the old plugins and create new plugins?
>
> This is a complete rewrite of Forrest. Doing it in a plugin will
> encorage us to reuse existing monolothic code in core.
Now i understand.
> If we had a 1.0 release already I would be proposing a 2.0 development.
> But we don't have one so this is a 1.0 development.
So when that branch comes back to replace trunk,
would it become the 0.9 release after that?
We also said that if necessary we could go to
0.10, 0.11, etc.
> It could be the other way around. 0.8 becomes the branch and we do this
> work in trunk. But I believe we need to have a "spring clean" (it must
> be spring for one of our developers)
I gather that we cannot do such reconstruction in the
trunk because we decided to keep it usable and do major
things in branches.
So then trunk becomes a maintenance place for the next
release, i.e. release 0.8 now, then branch and do the
refactoring there, with only bugfixes in the trunk.
The website documentation gets published from this new
development branch.
Is that how others see it?
-David
Starting a 1.0 development (Re: [Proposal] rollback)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>Diwaker Gupta wrote:
>>
>>>Thorsten Scherler wrote:
>>>
>>>
>>>>>Added two new plugins for
>>>>>refactoring views into the core:
>>>>>- structurer
>>>>>- themes
>>>>>
>>>>>Recent changes to views with using jxtg as core component
>>>>>made the old view plugins unusable (FOR-675)
>>>>>which can not longer stay like this.
>>>>>
>>>>>I recommend to rollback:
>>>>>- org.apache.forrest.plugin.internal.view
>>>>>- org.apache.forrest.plugin.output.viewHelper.xhtml
>>>>>to revision -r280939 and then commit them back as views head.
>>>
>>>Why can't we just roll back trunk to a stable version, and move the
>>>views/xhtml2 work to a new branch? I think thats much neater, and easier
>>>both on devs and users alike. People can hack away on the views/xhtml2
>>>branch without having to worry about breaking trunk for someone.
>>
>>+1
>>
>>In fact this is exactly what we agreed in the IRC session:
>>
>>Sep 19 11:17:31 <tscherler> - we should get the xhtml2 and view internal
>>together
>>Sep 19 11:18:03 <tscherler> - xhtml2 should be merged into the internal
>>views stuff, simply replace the docuemnt2html part
>>Sep 19 11:18:42 <tscherler> - x2 plugin should provide xdocs2x2
>>convertion
>>Sep 19 11:19:17 <tscherler> - views should work with x2 input
>>Sep 19 11:21:15 <tscherler> - we need to write a x2 to xhtml plugin
>>Sep 19 11:21:52 <tscherler> that should be basically a bunch of contracts
>>Sep 19 11:22:19 <tscherler> roadmap:
>>Sep 19 11:22:31 <tscherler> 1) create new branch
>>Sep 19 11:22:48 <tscherler> 2) move view stuff and x2 stuff into core
>>Sep 19 11:23:10 <tscherler> 3) resolving by both only allowed through lm
>>Sep 19 11:23:37 <tscherler> 4) create xdocs2x2 plugin
>>Sep 19 11:24:10 <tscherler> 5) create x2 to xhtml plugin
>>Sep 19 11:24:41 <tscherler> in this branch all skins are removed
>>Sep 19 11:24:52 <tscherler> only view is supported
>>Sep 19 11:25:19 <tscherler> skin pipes are to be refactored to output
>>xhtml2
>
>
> Hold on. That IRC discussion was extremely rushed at the end.
> We did not make any decisions there. Someone was going to make
> a proposal. Are you sure that a branch is the way to do this?
Yes, you are right. Lets start discussing the proposal in the open.
> Branches tend to become islands of lone development, and when
> they go on for too long, become hard to merge.
This work will touch pretty much *all* of Forrest. It will introduce:
- XHTML2 - rewrite of core processing pipelines
- Views - rewrite of core processing pipelines
- Locationmap - rewrite of core processing pipelines
So...
> How will this branch be merged? I see some confusing quick
> comments in that IRC log, but no resolution.
We didn't foresee merging this branch, rather replacing the current trunk:
Sep 19 11:32:23 <tscherler> that and is needed for an internal skin plugin
Sep 19 11:32:29 <rgardler> David: after we merge this beast? -> I do not
see us merging this branch, I see this as a compelte rewrite
Sep 19 11:32:40 <rgardler> all the stripped out stuff goes in plugins
Sep 19 11:32:54 <tscherler> +1
Sep 19 11:32:55 <rgardler> we are lef with a really clean core that does
nothing but the structurer part
Sep 19 11:33:30 <crossley> radical. So we cease development on trunk?
Sep 19 11:33:33 <rgardler> If you know Eclipse you'll understand the
beuaty of this
Sep 19 11:34:02 <rgardler> if not, think of Jedit - similar concept,
Sep 19 11:34:12 <rgardler> JEdit does nothing but provide a text editor
and a plugin frameowrk
Sep 19 11:34:33 <tscherler> (02:33:47) crossley: radical. So we cease
development on trunk?-> basically it should become a stable branch
Sep 19 11:34:47 <tscherler> like cocoon-2.1.x
Sep 19 11:34:51 <rgardler> Yes, make a 0.8 release and only do bug fixes
Sep 19 11:35:49 <tscherler> that would not meet "usable trunk " approach
but we can have 0.8 branch for that
Sep 19 11:35:58 <tscherler> better 0.8.x
Sep 19 11:36:27 <rgardler> I think we are in the mechanics now, that is
easy to do onlist
And so here we are onlist ;-)
> The thing that really frightens me is the comment
> "in this branch all skins are removed". Perhaps that is
> what is needed, but we must decide and not just an offhand
> comment in an IRC log.
Yes, you raised this issue onIRC too:
Sep 19 11:28:57 <crossley> So the old "skins" still continue to function?
Sep 19 11:29:11 <crossley> after we merge this beast?
Sep 19 11:29:17 <tscherler> no
Sep 19 11:29:26 <rgardler> We can make an internal plugin that provides
backward compatability
Sep 19 11:29:33 <tscherler> yes
Sep 19 11:29:39 <rgardler> I think we need to do that otherwise users
will not upgrade
Sep 19 11:29:51 <tscherler> +1
Sep 19 11:30:00 <crossley> rgardler: good but is that possible
Sep 19 11:30:08 <tscherler> yes it isd
Sep 19 11:30:22 <rgardler> Yes, at worst we simply take trunk and make
it a plugin ;-)
Sep 19 11:30:31 <tscherler> +1
In other words, core will *not* have skin functionality. It will only be
available in a (deprecated?) plugin.
> What was wrong with Thorsten's proposal to cease work
> on the old plugins and create new plugins?
This is a complete rewrite of Forrest. Doing it in a plugin will
encorage us to reuse existing monolothic code in core.
If we had a 1.0 release already I would be proposing a 2.0 development.
But we don't have one so this is a 1.0 development.
It could be the other way around. 0.8 becomes the branch and we do this
work in trunk. But I believe we need to have a "spring clean" (it must
be spring for one of our developers)
Ross
Re: [Proposal] rollback
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Diwaker Gupta wrote:
> >Thorsten Scherler wrote:
> >
> >>>Added two new plugins for
> >>>refactoring views into the core:
> >>>- structurer
> >>>- themes
> >>>
> >>>Recent changes to views with using jxtg as core component
> >>>made the old view plugins unusable (FOR-675)
> >>>which can not longer stay like this.
> >>>
> >>>I recommend to rollback:
> >>>- org.apache.forrest.plugin.internal.view
> >>>- org.apache.forrest.plugin.output.viewHelper.xhtml
> >>>to revision -r280939 and then commit them back as views head.
> >
> >Why can't we just roll back trunk to a stable version, and move the
> >views/xhtml2 work to a new branch? I think thats much neater, and easier
> >both on devs and users alike. People can hack away on the views/xhtml2
> >branch without having to worry about breaking trunk for someone.
>
> +1
>
> In fact this is exactly what we agreed in the IRC session:
>
> Sep 19 11:17:31 <tscherler> - we should get the xhtml2 and view internal
> together
> Sep 19 11:18:03 <tscherler> - xhtml2 should be merged into the internal
> views stuff, simply replace the docuemnt2html part
> Sep 19 11:18:42 <tscherler> - x2 plugin should provide xdocs2x2
> convertion
> Sep 19 11:19:17 <tscherler> - views should work with x2 input
> Sep 19 11:21:15 <tscherler> - we need to write a x2 to xhtml plugin
> Sep 19 11:21:52 <tscherler> that should be basically a bunch of contracts
> Sep 19 11:22:19 <tscherler> roadmap:
> Sep 19 11:22:31 <tscherler> 1) create new branch
> Sep 19 11:22:48 <tscherler> 2) move view stuff and x2 stuff into core
> Sep 19 11:23:10 <tscherler> 3) resolving by both only allowed through lm
> Sep 19 11:23:37 <tscherler> 4) create xdocs2x2 plugin
> Sep 19 11:24:10 <tscherler> 5) create x2 to xhtml plugin
> Sep 19 11:24:41 <tscherler> in this branch all skins are removed
> Sep 19 11:24:52 <tscherler> only view is supported
> Sep 19 11:25:19 <tscherler> skin pipes are to be refactored to output
> xhtml2
Hold on. That IRC discussion was extremely rushed at the end.
We did not make any decisions there. Someone was going to make
a proposal. Are you sure that a branch is the way to do this?
Branches tend to become islands of lone development, and when
they go on for too long, become hard to merge.
How will this branch be merged? I see some confusing quick
comments in that IRC log, but no resolution.
The thing that really frightens me is the comment
"in this branch all skins are removed". Perhaps that is
what is needed, but we must decide and not just an offhand
comment in an IRC log.
What was wrong with Thorsten's proposal to cease work
on the old plugins and create new plugins?
-David
Re: [Proposal] rollback
Posted by Ross Gardler <rg...@apache.org>.
Diwaker Gupta wrote:
> On Tuesday 27 September 2005 5:08 pm, Thorsten Scherler wrote:
>
>>>Added two new plugins for
>>>refactoring views into the core:
>>>- structurer
>>>- themes
>>>
>>>Recent changes to views with using jxtg as core component
>>>made the old view plugins unusable (FOR-675)
>>>which can not longer stay like this.
>>>
>>>I recommend to rollback:
>>>- org.apache.forrest.plugin.internal.view
>>>- org.apache.forrest.plugin.output.viewHelper.xhtml
>>>to revision -r280939 and then commit them back as views head.
>
>
> Why can't we just roll back trunk to a stable version, and move the
> views/xhtml2 work to a new branch? I think thats much neater, and easier both
> on devs and users alike. People can hack away on the views/xhtml2 branch
> without having to worry about breaking trunk for someone.
>
+1
In fact this is exactly what we agreed in the IRC session:
Sep 19 11:17:31 <tscherler> - we should get the xhtml2 and view internal
together
Sep 19 11:18:03 <tscherler> - xhtml2 should be merged into the internal
views stuff, simply replace the docuemnt2html part
Sep 19 11:18:42 <tscherler> - x2 plugin should provide xdocs2x2 convertion
Sep 19 11:19:17 <tscherler> - views should work with x2 input
Sep 19 11:21:15 <tscherler> - we need to write a x2 to xhtml plugin
Sep 19 11:21:52 <tscherler> that should be basically a bunch of contracts
Sep 19 11:22:19 <tscherler> roadmap:
Sep 19 11:22:31 <tscherler> 1) create new branch
Sep 19 11:22:48 <tscherler> 2) move view stuff and x2 stuff into core
Sep 19 11:23:10 <tscherler> 3) resolving by both only allowed through lm
Sep 19 11:23:37 <tscherler> 4) create xdocs2x2 plugin
Sep 19 11:24:10 <tscherler> 5) create x2 to xhtml plugin
Sep 19 11:24:41 <tscherler> in this branch all skins are removed
Sep 19 11:24:52 <tscherler> only view is supported
Sep 19 11:25:19 <tscherler> skin pipes are to be refactored to output xhtml2
Ross
Re: [Proposal] rollback
Posted by Diwaker Gupta <di...@apache.org>.
On Tuesday 27 September 2005 5:08 pm, Thorsten Scherler wrote:
> > Added two new plugins for
> > refactoring views into the core:
> > - structurer
> > - themes
> >
> > Recent changes to views with using jxtg as core component
> > made the old view plugins unusable (FOR-675)
> > which can not longer stay like this.
> >
> > I recommend to rollback:
> > - org.apache.forrest.plugin.internal.view
> > - org.apache.forrest.plugin.output.viewHelper.xhtml
> > to revision -r280939 and then commit them back as views head.
Why can't we just roll back trunk to a stable version, and move the
views/xhtml2 work to a new branch? I think thats much neater, and easier both
on devs and users alike. People can hack away on the views/xhtml2 branch
without having to worry about breaking trunk for someone.
--
Web/Blog/Gallery: http://floatingsun.net
On Apache: http://people.apache.org/~diwaker
Re: [Proposal] rollback -
internal.view and output.viewHelper.xhtml to revision 280939 (was Re: svn
commit: r292072)
Posted by Thorsten Scherler <th...@apache.org>.
El mié, 28-09-2005 a las 23:32 +0100, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > El mié, 28-09-2005 a las 21:45 +0100, Ross Gardler escribió:
> > ...
>
> ...
>
> >> Unfortunately, I cannot give examples from it as the
> >>organisation has not permitted me to open source that part of the code.
>
> ...
>
> > To bad that there are still companies that like using os but do not want give anything back.
> > I made some experience on that as well and it is a bummer.
>
> Actually, this particular organisation has contributed a hell of a lot
> to Forrest (and to many other OS products).
Thanks very much to this organisation. I did not want to say this to
offend anyone. Please keep on supporting us by letting devs release code
back to the core. It it helping you even ...
> They just don't want to
> contribute this particular part of their system since it is part of
> their competitive advantage right now.
Yes, that is the reason I could not release the inx plugin. :(
> In the past they have done the
> same, but when competitors caught up they have donated back.
Hmm, software as competitive advantage is short term only, I am afraid.
The optimization of the involved process supported by this software will
lead to longer term strategic advantages.
...but that leads to strategic managements theories and M. Porter where
you will find exceptions for above said...
Anyway, I can fully understand that they do not feel to donate it back.
This is the phenomenon of free riding which is really bad in OS.
Competitors will use your donations but not having the producing costs.
Sad but true. :(
> (got to say that because I know some of them are in here ;-)
>
(had to reply to it because of this ;-)
> > Anyway I would be glad to see a simple example how you did it as soon as you find some time.
>
> No problem. I'm keen to see the new branch so I can do it in there, the
> organisation has *not* restricted changes to Forrest Core, only to the
> plugin. So it is only a matter of my finding time.
>
> Ross
>
:)
You can even make an example in an email I do not care. ;-)
Anyway, I will create now the new branch.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [Proposal] rollback - internal.view and output.viewHelper.xhtml
to revision 280939 (was Re: svn commit: r292072)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El mié, 28-09-2005 a las 21:45 +0100, Ross Gardler escribió:
> ...
...
>> Unfortunately, I cannot give examples from it as the
>>organisation has not permitted me to open source that part of the code.
...
> To bad that there are still companies that like using os but do not want give anything back.
> I made some experience on that as well and it is a bummer.
Actually, this particular organisation has contributed a hell of a lot
to Forrest (and to many other OS products). They just don't want to
contribute this particular part of their system since it is part of
their competitive advantage right now. In the past they have done the
same, but when competitors caught up they have donated back.
(got to say that because I know some of them are in here ;-)
> Anyway I would be glad to see a simple example how you did it as soon as you find some time.
No problem. I'm keen to see the new branch so I can do it in there, the
organisation has *not* restricted changes to Forrest Core, only to the
plugin. So it is only a matter of my finding time.
Ross
Re: [Proposal] rollback - internal.view
and output.viewHelper.xhtml to revision 280939 (was Re: svn commit: r292072)
Posted by Thorsten Scherler <th...@apache.org>.
El mié, 28-09-2005 a las 21:45 +0100, Ross Gardler escribió:
...
> Hmmm... there is nothing in the log you quote that says I am to provide
> an example. The Resume plugin I refer to is an adaption of the plugin
> in SVN. Unfortunately, I cannot give examples from it as the
> organisation has not permitted me to open source that part of the code.
> I hope to implement something similar in the Amazon ECS plugin as that
> is for a voluntary organisation that understands the idea of sharing.
> However, it is a voluntary organisation, so don't hold your breath, work
> will happen only when time allows.
>
> It works like this:
>
> resume src -> contracts -> XDoc -> XDoc2XHTML.xsl -> CSS -> themed page
>
> This is explained in more detail in my mail outlining my approach to
> integrating XHTML2 and is discussed further in the rest of the IRC log.
Dude, sorry that it may came around wee bit different that I indented. I
actually do not understand how you did
resume src -> contracts -> XDoc
that was the reason I asked again. Till now if you use contracts you
have to go through the plugins but it seems you found out how to use
contracts in a better way. I am really keen to learn myself how we can
enhance views and your description sounds wonderful.
To bad that there are still companies that like using os but do not want give anything back.
I made some experience on that as well and it is a bummer.
Anyway I would be glad to see a simple example how you did it as soon as you find some time.
Cheers
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [Proposal] rollback - internal.view and output.viewHelper.xhtml
to revision 280939 (was Re: svn commit: r292072)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El mié, 28-09-2005 a las 14:39 +0200, Thorsten Scherler escribió:
>
>>El mié, 28-09-2005 a las 09:34 +0100, Ross Gardler escribió:
>>...
>>
>>>I note that your theme plugin contains all the contracts rather than
>>>just the theme, is this a result of copying the branch and we are still
>>>in agreement about the above processing pipeline? In other words we are
>>>going to refactor the structure of this plugin at some point in the future?
>>
>>I am refactoring them, that is why they broke the trunk!
>
>
> ...
> BTW I am waiting for the example:
Hmmm... there is nothing in the log you quote that says I am to provide
an example. The Resume plugin I refer to is an adaption of the plugin
in SVN. Unfortunately, I cannot give examples from it as the
organisation has not permitted me to open source that part of the code.
I hope to implement something similar in the Amazon ECS plugin as that
is for a voluntary organisation that understands the idea of sharing.
However, it is a voluntary organisation, so don't hold your breath, work
will happen only when time allows.
It works like this:
resume src -> contracts -> XDoc -> XDoc2XHTML.xsl -> CSS -> themed page
This is explained in more detail in my mail outlining my approach to
integrating XHTML2 and is discussed further in the rest of the IRC log.
Ross
> Sep 19 09:29:57 <rgardler> contracts(core) - they are used in core, they
> may be provided by an input plugin though, e.g. resume plugin has
> contracts that convert from resume DTD to XHTML2
> Sep 19 09:52:38 <rgardler> Have you looked at the Resume plugin? (I ask
> so that I know where to pitch my explanation)
> Sep 19 09:52:55 <twilliams_> but i don't see how the contract itself "contracts produce XHTML2 for consumption in the core"
> Sep 19 09:53:27 <tscherler> (00:53:11) twilliams_: but i don't see how the contract itself "contracts produce XHTML2 for consumption in the core"-> I just looking at the resume plugin and do not dsee this either
> Sep 19 09:53:30 <twilliams_> noo
> Sep 19 09:53:46 <twilliams_> i can though if it won't waste folks time
> Sep 19 09:54:32 <rgardler> No, I need to explain it Tim
> Sep 19 09:54:45 <rgardler> The resume plugin uses a resume DTD as input
> Sep 19 09:55:41 <rgardler> (I just realised the committed version of the plugin doesn't do this - no wonder you are all confused - sorry)
>
> salu2
Re: [Proposal] rollback - internal.view and
output.viewHelper.xhtml to revision 280939 (was Re: svn commit: r292072)
Posted by Thorsten Scherler <th...@apache.org>.
El mié, 28-09-2005 a las 14:39 +0200, Thorsten Scherler escribió:
> El mié, 28-09-2005 a las 09:34 +0100, Ross Gardler escribió:
> ...
> > I note that your theme plugin contains all the contracts rather than
> > just the theme, is this a result of copying the branch and we are still
> > in agreement about the above processing pipeline? In other words we are
> > going to refactor the structure of this plugin at some point in the future?
>
> I am refactoring them, that is why they broke the trunk!
...
BTW I am waiting for the example:
Sep 19 09:29:57 <rgardler> contracts(core) - they are used in core, they
may be provided by an input plugin though, e.g. resume plugin has
contracts that convert from resume DTD to XHTML2
Sep 19 09:52:38 <rgardler> Have you looked at the Resume plugin? (I ask
so that I know where to pitch my explanation)
Sep 19 09:52:55 <twilliams_> but i don't see how the contract itself "contracts produce XHTML2 for consumption in the core"
Sep 19 09:53:27 <tscherler> (00:53:11) twilliams_: but i don't see how the contract itself "contracts produce XHTML2 for consumption in the core"-> I just looking at the resume plugin and do not dsee this either
Sep 19 09:53:30 <twilliams_> noo
Sep 19 09:53:46 <twilliams_> i can though if it won't waste folks time
Sep 19 09:54:32 <rgardler> No, I need to explain it Tim
Sep 19 09:54:45 <rgardler> The resume plugin uses a resume DTD as input
Sep 19 09:55:41 <rgardler> (I just realised the committed version of the plugin doesn't do this - no wonder you are all confused - sorry)
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [Proposal] rollback - internal.view
and output.viewHelper.xhtml to revision 280939 (was Re: svn commit: r292072)
Posted by Thorsten Scherler <th...@apache.org>.
El mié, 28-09-2005 a las 21:46 +0100, Ross Gardler escribió:
...
>
> >>Assuming that we are still in agreement we should really get some
> >>representation of this diagram into our TR, perhaps with some of the
> >>discussion from those threads too.
> >
> >
> > Just go ahead and do it.
>
> Yeah, I know. But one has to have the time. I spent alot of time writing
> the mail in the first place. I mention it here in case someone else has
> the time to leverage that documentation before I do.
I know what you are talking about but there are sadly only a handful
that actually are doing it. I felt you was asking me personally to do it
and sadly my todo list is too crowed to add another task. :( That is the
reason of that sentence.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [Proposal] rollback - internal.view and output.viewHelper.xhtml
to revision 280939 (was Re: svn commit: r292072)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El mié, 28-09-2005 a las 09:34 +0100, Ross Gardler escribió:
> ...
>
>>I note that your theme plugin contains all the contracts rather than
>>just the theme, is this a result of copying the branch and we are still
>>in agreement about the above processing pipeline? In other words we are
>>going to refactor the structure of this plugin at some point in the future?
>
>
> I am refactoring them, that is why they broke the trunk!
That's cool then, just checking.
>>Assuming that we are still in agreement we should really get some
>>representation of this diagram into our TR, perhaps with some of the
>>discussion from those threads too.
>
>
> Just go ahead and do it.
Yeah, I know. But one has to have the time. I spent alot of time writing
the mail in the first place. I mention it here in case someone else has
the time to leverage that documentation before I do.
Ross
Re: [Proposal] rollback - internal.view and
output.viewHelper.xhtml to revision 280939 (was Re: svn commit: r292072)
Posted by Thorsten Scherler <th...@apache.org>.
El mié, 28-09-2005 a las 09:34 +0100, Ross Gardler escribió:
...
> I note that your theme plugin contains all the contracts rather than
> just the theme, is this a result of copying the branch and we are still
> in agreement about the above processing pipeline? In other words we are
> going to refactor the structure of this plugin at some point in the future?
I am refactoring them, that is why they broke the trunk!
> Assuming that we are still in agreement we should really get some
> representation of this diagram into our TR, perhaps with some of the
> discussion from those threads too.
Just go ahead and do it.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [Proposal] rollback - internal.view and output.viewHelper.xhtml
to revision 280939 (was Re: svn commit: r292072)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El mar, 27-09-2005 a las 23:59 +0000, thorsten@apache.org escribió:
...
>>Added:
>
> - structurer
OK
> - themes
This themes plugin contains contracts that only define content. In our
respective mails [1][2] regarding what it means to have XHTML2 in core
we both drew the processing pipeline. We both had identical diagrams
(well there was some labelling and position differences but they show
the same flow):
theme
|
\|/
src -> input plugin -> core (views) -> output plugin -> output
| | /|\ /|\
| | | |
| | \ +------------------+ |
| +---------- |forrest:contracts | |
| / |forrest:properties| |
| +------------------+ |
| |
| |
+--------------------------------------------------------+
and
theme
|
\|/
core (views) -> output plugin (views can bypass them) -> output
| /|\
\|/ |
+------------------+ +-----------------+
|forrest:contracts |--->| input plugin |
|forrest:properties|<---|src (+navigation)|
+------------------+ +-----------------+
We discussed these in the IRC session and agreed that they are
essentially the same thing.
Interestingly Johannes also created the same process, having approached
the issue from a completely different angle [3].
I note that your theme plugin contains all the contracts rather than
just the theme, is this a result of copying the branch and we are still
in agreement about the above processing pipeline? In other words we are
going to refactor the structure of this plugin at some point in the future?
Assuming that we are still in agreement we should really get some
representation of this diagram into our TR, perhaps with some of the
discussion from those threads too.
Ross
[1] http://marc.theaimsgroup.com/?l=forrest-dev&m=112674219803048&w=2
[2] http://marc.theaimsgroup.com/?l=forrest-dev&m=112706372323582&w=2
[3] http://marc.theaimsgroup.com/?l=forrest-dev&m=112720001514522&w=2
[Proposal] rollback - internal.view and output.viewHelper.xhtml to
revision 280939 (was Re: svn commit: r292072)
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 27-09-2005 a las 23:59 +0000, thorsten@apache.org escribió:
> Author: thorsten
> Date: Tue Sep 27 16:59:14 2005
> New Revision: 292072
>
> URL: http://svn.apache.org/viewcvs?rev=292072&view=rev
> Log:
> Added two new plugins for
> refactoring views into the core:
> - structurer
> - themes
>
> Recent changes to views with using jxtg as core component
> made the old view plugins unusable (FOR-675)
> which can not longer stay like this.
>
> I recommend to rollback:
> - org.apache.forrest.plugin.internal.view
> - org.apache.forrest.plugin.output.viewHelper.xhtml
> to revision -r280939 and then commit them back as views head.
>
> The changes not related to jx could be readded via patches from svn log.
>
> This will solve FOR-678 for old views plugin and use the new plugins
> to incoperate forrest:views into the core.
>
> The new plugins will still suffer from FOR-678!
>
> Added:
- structurer
- themes
...
WDYT?
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)