You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Diana Shannon <sh...@apache.org> on 2002/07/04 05:27:56 UTC
Need todo list for Cocoon transition
I'm still a little confused about what exactly remains for Cocoon to
begin its transition to Forrest. Can someone please enlighten me by
helping to complete a todo list? I thought David and I had trudged
through most of the hard work already. I feel good about the state of
the docs. I'm psyched to get going with Forrest and its promise. So,
what remains to do?
Seems to me:
1. Skin has to be decided by cocoon-dev, right? If so, shouldn't we get
this process started on cocoon-dev?
2. Build targets need to be added to address all of Cocoon's current
builds.
3. Cocoon CVS needs some revisions
- add forrest.xgump
- add build facilities and targets
- ? Is the Forrest CVS adapting to Cocoon CVS structure or vice versa?
4. Tab decisions (IMO these could wait).
5. URISpace decisions (IMO these could also wait)
... what else?
Issues
How do we address the differences between different versions of Cocoon
in branches. Currently docs builds in HEAD are created with Cocoon 2.1;
release uses 2.0.3. Will these differences affect Forrest-generated
builds? Remember, we still need to have users be able to build their own
docs from local cvs repositories based on multiple branches, don't we?
Target Date
I'd like to complete this before 2.1 beta of Cocoon. Is it feasible?
Even if we can't automate the web site updates yet, we could still
transition to the necessary architecture, correct? Honestly, I'd prefer
to continue with manual updates until we arrive at a comfort zone with
all transition issues.
Thanks for your guidance.
Diana
Re: Tab Issues (was: Re: Need todo list for Cocoon transition)
Posted by Bert Van Kets <be...@vankets.com>.
At 12:26 4/07/2002 -0400, you wrote:
>Now, tabs.
>
><diana>
>4. Tab decisions (IMO these could wait).
></diana?
>
><steven>
>you will need to add some tabs, I believe, but that's dead simple.
></steven>
>
><david>
>As far as i can tell, tabs do not work yet.
></david>
>
><konstantin>
>They work, but you have to perform some hacky things to make them behave as
>expected...
></konstantin>
>
>Issues
>1. Steven, you used the term "dead simple." Maybe dead simple to
>implement, but IMHO deciding what content goes under what tab should be
>decided on cocoon-dev. If so, IMHO it needs to be proposed on cocoon-dev.
>Is anyone working on a proposal? I started assessing this when I first
>started looking at the Cocoon web site and its doc issues. Should we
>create a draft proposal here on Forrest and then post it for comments and
>feedback on cocoon-dev? If so, should I refactor an old email of mine and
>post a draft here for more tab-specific comments?
>
>2. Bert, do you have time to fix the so-called hacky things, or should we
>wait to get feedback from cocoon-dev about what to do about the overall
>skin issue first?
I'm lurking at the moment due to overwork on my and my wife's day
jobs. What timeframe are you thinking about?
I got some solutions from Konstantin (I think), but still need to sort it
out the details.
Bert
>Diana
Re: Target Date Issues (was: Re: Need todo list for Cocoon transition)
Posted by Steven Noels <st...@outerthought.org>.
Diana Shannon wrote:
> <steven>
> As I said, the documents seem pretty well shaped up. When do you plan to
> make the transition to v11 DTDs? Or would you still be using the upgrade
> XSLT?
> </steven>
>
> I guess it boils down to a skin issue, doesn't it. When I did the
> original conversion, I added Cocoon docs to the Forrest CVS. I'll report
> back, after I try it the other way. Seems to me there will be issues
> with existing XSLTs, but let me find out.
Nitpicking on terminology: a skin should only be responsible for
rendition concerns, doing pre-publishing/skinning transformations should
not be part of a 'skin' but of a project-specific pipeline, IF we allow
people to use Forrest without adopting 'our' DTDs.
Your comments, please - I know this might sound harsh but I don't want
to be everything for everybody.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
Target Date Issues (was: Re: Need todo list for Cocoon transition)
Posted by Diana Shannon <sh...@apache.org>.
Finally, target date, in two parts.
PART ONE: Target Date for Completion
<diana>
I'd like to complete this before 2.1 beta of Cocoon. Is it feasible?
</diana>
<steven>
When is that beta 'planned'?
</steven>
<david>
The cocoon/plan/release.xml says
August/September 2002 : Release date for 2.1 Alpha 1
No mention of further releases as yet.
</david>
<steven>
Ah. Plenty of time :-)
</steven>
<snip what="konstantin" why="dream mode, save for later" />
Plenty of time? Maybe, but I want to start asap. In fact, it has
started, I'm ready to dig into the cvs. I was basing my proposal on the
original date, proposed by Carsten, which has since slipped (sorry,
forgot this). I sure hope we can complete this effort -- with or without
remote building -- by August.
Still reasonable? Remember, lack of Forrest kills my efficiency. There's
so many useful, real world things we can add to Forrest, but I don't
want to design them in the abstract based on the very simple docs that
Forrest currently has. I want them to be based a real need, Cocoon, one
that's so in my face that it makes sense to for me to fix the problem
instead of continuing to hack away with tedious, manual fixes. That's
why I've stopped contributing patches to Forrest. I'd rather wait and
see what I *really* need, what the priorities are. Then, I'll have lots
of concrete patches to offer for your feedback and wise advice...
Forrest needs Cocoon as a test case, and the sooner the better IMNSHO.
PART TWO: What else can we do right now?
<diana>
Even if we can't automate the web site updates yet, we could still
transition to the necessary architecture, correct? Honestly, I'd prefer
to continue with manual updates until we arrive at a comfort zone with
all transition issues.
</diana>
<steven>
As I said, the documents seem pretty well shaped up. When do you plan to
make the transition to v11 DTDs? Or would you still be using the upgrade
XSLT?
</steven>
I guess it boils down to a skin issue, doesn't it. When I did the
original conversion, I added Cocoon docs to the Forrest CVS. I'll report
back, after I try it the other way. Seems to me there will be issues
with existing XSLTs, but let me find out.
Diana
Re: Need todo list for Cocoon transition
Posted by Bert Van Kets <be...@vankets.com>.
>>><snip/>
>>>
>>>
>>>>4. Tab decisions (IMO these could wait).
>>>
>>>you will need to add some tabs, I believe, but that's dead simple.
>>
>>As far as i can tell, tabs do not work yet.
>
>Oops. Bert, can you confirm this?
They do work here. The target directory is still hardcoded at line 17 in
tab2menu.xsl. :-(
I must get some time to fix this. I'm way behind on a payed job, so not
much (none) free time left. :'-(
I'll do my best to look at this ASAP.
Bert
<snip/>
Re: Need todo list for Cocoon transition
Posted by Steven Noels <st...@outerthought.org>.
David Crossley wrote:
>>yep (and please refrain from building your own skin ;-)
>
>
> Why do you say that? I imagine that many projects will not
> want the default Forrest skin and will want to use their own.
> I do understand that for this stage of Forrest it would be
> far easier to just stick with the default.
Both easiness and consistency, IMO. One of the goals of Forrest is to
have a uniform xml.apache.org website. The skinning system is mainly
targeted towards projects externally to xml.apache.org.
> Has Forrest yet decided how broad is the scope of its skin?
Nope - but that's my feeling towards it. Am I wrong?
> I am confused as to the intention. Is the skin just for
> Forrest home and community docs, or does it apply to all
> projects?
All xml.apache.org projects IMO.
>>IMO, the 'bert' skin is the obvious choice right now
>>
>>
>>>2. Build targets need to be added to address all of Cocoon's current
>>>builds.
>>
>>well... I have been planning (and postponing) to clean up the current
>>forrest build environment and *finally* support remote project building
>>- unfortunately, I will not be able to work on this before next week.
>
>
> A while ago Ken said that he would attend to upgrading
> Forrest's Centipede (which includes the Ant 1.5) to enable
> the use of the scratchpad 'transform-v11' targets.
> So be careful of effort overlap.
The more I am looking at the current build system, the more I get the
feeling it is too much for what we are currently doing. I'd be happy if
Nicola patches it, even adding that new 'import' tag he is currently
advocating, but I want to move forward. I'm not so sure whether his and
my plans would conflict, but I'll keep everyone informed so that we can
minimize that risk.
>>Given that, there shouldn't be any adaptation necessary anymore.
>>
>>
>>>3. Cocoon CVS needs some revisions
>>> - add forrest.xgump
>>> - add build facilities and targets
>>> - ? Is the Forrest CVS adapting to Cocoon CVS structure or vice versa?
>>
>>I checked the src/documentation structure of current Cocoon CVS and it
>>seems pretty well shaped up for Forrest remote project building.
>>
>>
>>>4. Tab decisions (IMO these could wait).
>>
>>you will need to add some tabs, I believe, but that's dead simple.
>
>
> As far as i can tell, tabs do not work yet.
Oops. Bert, can you confirm this?
>>>5. URISpace decisions (IMO these could also wait)
>>
>>yep
>>
>>
>>>... what else?
>>>
>>>Issues
>>>How do we address the differences between different versions of Cocoon
>>>in branches. Currently docs builds in HEAD are created with Cocoon 2.1;
>>>release uses 2.0.3. Will these differences affect Forrest-generated
>>>builds? Remember, we still need to have users be able to build their own
>>>docs from local cvs repositories based on multiple branches, don't we?
>>
>>there's no concept of CVS branches inside project.xtarget right now, but
>>it should be possible to add those and run Forrest across both branches
>>- something we should add to the forrest.xconf descriptor, I guess.
>>
>>
>>>Target Date
>>>I'd like to complete this before 2.1 beta of Cocoon. Is it feasible?
>>
>>When is that beta 'planned'?
>
>
> The cocoon/plan/release.xml says
> August/September 2002 : Release date for 2.1 Alpha 1
> No mention of further releases as yet.
Ah. Plenty of time :-)
>>>Even if we can't automate the web site updates yet, we could still
>>>transition to the necessary architecture, correct? Honestly, I'd prefer
>>>to continue with manual updates until we arrive at a comfort zone with
>>>all transition issues.
>>
>>As I said, the documents seem pretty well shaped up. When do you plan to
>>make the transition to v11 DTDs? Or would you still be using the upgrade
>>XSLT?
>>
>>
>>>Thanks for your guidance.
>>
>>I need to get Forrest in a better shape by the end of next week for a
>>customer - so hopefully I'll be able to add this remote project building
>>support 'RSN'(tm).
>
>
> Excellent.
> --David
Warm regards,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
Re: Need todo list for Cocoon transition
Posted by David Crossley <cr...@indexgeo.com.au>.
Steven Noels wrote:
> Diana Shannon wrote:
>
> > I'm still a little confused about what exactly remains for Cocoon to
> > begin its transition to Forrest. Can someone please enlighten me by
> > helping to complete a todo list? I thought David and I had trudged
> > through most of the hard work already. I feel good about the state of
> > the docs. I'm psyched to get going with Forrest and its promise. So,
> > what remains to do?
> >
> > Seems to me:
> >
> > 1. Skin has to be decided by cocoon-dev, right? If so, shouldn't we get
> > this process started on cocoon-dev?
>
> yep (and please refrain from building your own skin ;-)
Why do you say that? I imagine that many projects will not
want the default Forrest skin and will want to use their own.
I do understand that for this stage of Forrest it would be
far easier to just stick with the default.
Has Forrest yet decided how broad is the scope of its skin?
I am confused as to the intention. Is the skin just for
Forrest home and community docs, or does it apply to all
projects?
> IMO, the 'bert' skin is the obvious choice right now
>
> > 2. Build targets need to be added to address all of Cocoon's current
> > builds.
>
> well... I have been planning (and postponing) to clean up the current
> forrest build environment and *finally* support remote project building
> - unfortunately, I will not be able to work on this before next week.
A while ago Ken said that he would attend to upgrading
Forrest's Centipede (which includes the Ant 1.5) to enable
the use of the scratchpad 'transform-v11' targets.
So be careful of effort overlap.
> Given that, there shouldn't be any adaptation necessary anymore.
>
> > 3. Cocoon CVS needs some revisions
> > - add forrest.xgump
> > - add build facilities and targets
> > - ? Is the Forrest CVS adapting to Cocoon CVS structure or vice versa?
>
> I checked the src/documentation structure of current Cocoon CVS and it
> seems pretty well shaped up for Forrest remote project building.
>
> > 4. Tab decisions (IMO these could wait).
>
> you will need to add some tabs, I believe, but that's dead simple.
As far as i can tell, tabs do not work yet.
> > 5. URISpace decisions (IMO these could also wait)
>
> yep
>
> > ... what else?
> >
> > Issues
> > How do we address the differences between different versions of Cocoon
> > in branches. Currently docs builds in HEAD are created with Cocoon 2.1;
> > release uses 2.0.3. Will these differences affect Forrest-generated
> > builds? Remember, we still need to have users be able to build their own
> > docs from local cvs repositories based on multiple branches, don't we?
>
> there's no concept of CVS branches inside project.xtarget right now, but
> it should be possible to add those and run Forrest across both branches
> - something we should add to the forrest.xconf descriptor, I guess.
>
> > Target Date
> > I'd like to complete this before 2.1 beta of Cocoon. Is it feasible?
>
> When is that beta 'planned'?
The cocoon/plan/release.xml says
August/September 2002 : Release date for 2.1 Alpha 1
No mention of further releases as yet.
> > Even if we can't automate the web site updates yet, we could still
> > transition to the necessary architecture, correct? Honestly, I'd prefer
> > to continue with manual updates until we arrive at a comfort zone with
> > all transition issues.
>
> As I said, the documents seem pretty well shaped up. When do you plan to
> make the transition to v11 DTDs? Or would you still be using the upgrade
> XSLT?
>
> > Thanks for your guidance.
>
> I need to get Forrest in a better shape by the end of next week for a
> customer - so hopefully I'll be able to add this remote project building
> support 'RSN'(tm).
Excellent.
--David
CVS issues (was: Re: Need todo list for Cocoon transition)
Posted by Diana Shannon <sh...@apache.org>.
Next, CVS:
<diana>
3. Cocoon CVS needs some revisions
- add forrest.xgump
- add build facilities and targets
- ? Is the Forrest CVS adapting to Cocoon CVS structure or vice versa?
</diana>
<steven>
I checked the src/documentation structure of current Cocoon CVS and it
seems pretty well shaped up for Forrest remote project building.
</steven>
But Forrest depends on more than what is located in xdocs. If Cocoon
needs to generate its own doc builds (for distro, etc.) it needs to
revise its CVS to include:
1. Revised xdocs, obviously. But the mechanism to accomplish this
quickly is done.
2. Revised files in resources: stylesheets, schema, entities, etc.
3. addition of forrest.xgump (and removal of changes.xml and todo.xml
etc. now factored into forrest.xgump, and modification of distro-doc
builds).
Also:
1. Forrest needs to add a build target which triggers the creation of
jars.xml.
Anything else?
Issues:
Do *all* stylesheet modifications/additions have to go through Forrest?
I hope not. I think you need to allow projects to have at least some
project-specific stylesheets. As a trivial example, I added a transform
step to Cocoon's FAQ generation which includes the same FAQ content on
the bottom of every FAQ page (instructions on how to add a FAQ to the
page). Perhaps not all projects will want this particular content layer.
If so, the ability to have project-specific stylesheets also means the
ability to modify the sitemap. Of course, no project needs to have the
ability to modify the sitemap to take advantage of Forrest, but I don't
see how you can prevent such modifications, especially for projects like
the Cocoon.
Diana
Re: Build targets (was: Re: Need todo list for Cocoon transition)
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Steven Noels wrote:
> Yep, the idea is to generate Ant build.xml snippets using XSLT starting
> from the forrest.xconf file and then include those using XML entities,
> the Ant or your new Import Task in the main build environment. I'm
> biased towards the Ant 'Ant' Task right now, since I assume it is
> working already and offers some isolation between the different projects
> being build by Forrest. But I would be happy to switch to another
> approach if someone suggests me to do so.
Instead of generating snippets and combine them with other
snippets to a build.xml, you can pull in premanufactured
XML from the XSLT:
<xsl:copy-of select="document('boilerplate.xml')/*/*"/>
You can even have a neat template for build.xml if you want:
<project xmlns:t="forrest.template">
...
<target name="dist" depends="dist-src">
<t:depends target="dist"/>
<copy todir="${dist.src.result.dir}">
<fileset refid="dist.src"/>
<t:dist-files/>
</copy>
and in the xslt use the copy-through, pull the project
specific config file into a variable $proj and use stuff
like
<xsl:template match="t:dist-files">
<xsl:apply-templates select="$proj/dist/additional-files"/>
</xsl:template>
<xsl:template match="dist/additional-files">
<fileset dir="{dir}" include="{filepattern}/>
</xsl:template>
(the t:depends got a bit lengthy, sorry)
Use a namespace for the project specific config if you want
to be sure that there will be no name clashes in the template
matches.
J.Pietschmann
Re: Build targets (was: Re: Need todo list for Cocoon transition)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steven Noels wrote:
> Nicola Ken Barozzi wrote:
>
>> Well, build one remotely, build all.
>> I have already made POI's site build remotely, and there are the tasks
>> for it already in the build.
>>
>> Steven knows it, and I assume he will use those to make it work for
>> Cocoon.
>
>
> Yep, the idea is to generate Ant build.xml snippets using XSLT starting
> from the forrest.xconf file and then include those using XML entities,
> the Ant or your new Import Task in the main build environment. I'm
> biased towards the Ant 'Ant' Task right now, since I assume it is
> working already and offers some isolation between the different projects
> being build by Forrest. But I would be happy to switch to another
> approach if someone suggests me to do so.
Templating.
Download Centipede beta2 and look in antipede.xtarget at how we download
the cents.
But that's a second step, it's easy.
What we need to do know is to tweak the poi site creation targets to
work with Cocoon.
Then I'll do the rest, I've already done it's really easy.
It's testing the process for the first projects that takes time, that's
what needs testing.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Build targets (was: Re: Need todo list for Cocoon transition)
Posted by Steven Noels <st...@outerthought.org>.
Nicola Ken Barozzi wrote:
> Well, build one remotely, build all.
> I have already made POI's site build remotely, and there are the tasks
> for it already in the build.
>
> Steven knows it, and I assume he will use those to make it work for Cocoon.
Yep, the idea is to generate Ant build.xml snippets using XSLT starting
from the forrest.xconf file and then include those using XML entities,
the Ant or your new Import Task in the main build environment. I'm
biased towards the Ant 'Ant' Task right now, since I assume it is
working already and offers some isolation between the different projects
being build by Forrest. But I would be happy to switch to another
approach if someone suggests me to do so.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
Re: Build targets (was: Re: Need todo list for Cocoon transition)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Diana Shannon wrote:
> Next, the build process.
>
> <diana>
> 2. Build targets need to be added to address all of Cocoon's current
> builds.
> </diana>
>
> <steven>
> well... I have been planning (and postponing) to clean up the current
> forrest build environment and *finally* support remote project building
> - unfortunately, I will not be able to work on this before next week.
>
> Given that, there shouldn't be any adaptation necessary anymore.
> </steven>
>
> <david>
> A while ago Ken said that he would attend to upgrading
> Forrest's Centipede (which includes the Ant 1.5) to enable
> the use of the scratchpad 'transform-v11' targets.
> So be careful of effort overlap.
> </david>
>
> <steven>
> The more I am looking at the current build system, the more I get the
> feeling it is too much for what we are currently doing. I'd be happy if
> Nicola patches it, even adding that new 'import' tag he is currently
> advocating, but I want to move forward. I'm not so sure whether his and
> my plans would conflict, but I'll keep everyone informed so that we can
> minimize that risk.
> </steven>
>
> Clarification needed: What is the scope of "remote project building"? Is
> it correct to assume:
>
> 1. Forrest's only concern is building Cocoon's web site, and it does
> that remotely.
Well, build one remotely, build all.
I have already made POI's site build remotely, and there are the tasks
for it already in the build.
Steven knows it, and I assume he will use those to make it work for Cocoon.
> 2. Cocoon continues with its own build environment (with some minor
> modifications) to produce *all* other doc-related (e.g. user docs in the
> distro) and other targets. In other words, Cocoon continues using just
> Ant, not Centipede, at least for now.
Well, Centipede is Ant++.
Currently Forrest is not using Centipede "plugins", so what you say it's
true.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Build targets (was: Re: Need todo list for Cocoon transition)
Posted by Diana Shannon <sh...@apache.org>.
Next, the build process.
<diana>
2. Build targets need to be added to address all of Cocoon's current
builds.
</diana>
<steven>
well... I have been planning (and postponing) to clean up the current
forrest build environment and *finally* support remote project
building - unfortunately, I will not be able to work on this before next
week.
Given that, there shouldn't be any adaptation necessary anymore.
</steven>
<david>
A while ago Ken said that he would attend to upgrading
Forrest's Centipede (which includes the Ant 1.5) to enable
the use of the scratchpad 'transform-v11' targets.
So be careful of effort overlap.
</david>
<steven>
The more I am looking at the current build system, the more I get the
feeling it is too much for what we are currently doing. I'd be happy if
Nicola patches it, even adding that new 'import' tag he is currently
advocating, but I want to move forward. I'm not so sure whether his and
my plans would conflict, but I'll keep everyone informed so that we can
minimize that risk.
</steven>
Clarification needed: What is the scope of "remote project building"? Is
it correct to assume:
1. Forrest's only concern is building Cocoon's web site, and it does
that remotely.
2. Cocoon continues with its own build environment (with some minor
modifications) to produce *all* other doc-related (e.g. user docs in the
distro) and other targets. In other words, Cocoon continues using just
Ant, not Centipede, at least for now.
Diana
Re: Tab Issues (was: Re: Need todo list for Cocoon transition)
Posted by Diana Shannon <sh...@apache.org>.
On Friday, July 5, 2002, at 04:45 AM, Steven Noels wrote:
>> Issues
>> 1. Steven, you used the term "dead simple." Maybe dead simple to
>> implement, but IMHO deciding what content goes under what tab should
>> be decided on cocoon-dev. If so, IMHO it needs to be proposed on
>> cocoon-dev. Is anyone working on a proposal? I started assessing this
>> when I first started looking at the Cocoon web site and its doc
>> issues. Should we create a draft proposal here on Forrest and then
>> post it for comments and feedback on cocoon-dev? If so, should I
>> refactor an old email of mine and post a draft here for more
>> tab-specific comments?
>
> Please do so.
>
> On the technical level: would a 'tab' map to a section handled by its
> own sitemap? Just an idea.
But I thought you were discouraging the use of multiple sitemaps...
http://marc.theaimsgroup.com/?l=forrest-dev&m=102252513231595&w=2
Diana
Re: Tab Issues (was: Re: Need todo list for Cocoon transition)
Posted by Steven Noels <st...@outerthought.org>.
Diana Shannon wrote:
> Issues
> 1. Steven, you used the term "dead simple." Maybe dead simple to
> implement, but IMHO deciding what content goes under what tab should be
> decided on cocoon-dev. If so, IMHO it needs to be proposed on
> cocoon-dev. Is anyone working on a proposal? I started assessing this
> when I first started looking at the Cocoon web site and its doc issues.
> Should we create a draft proposal here on Forrest and then post it for
> comments and feedback on cocoon-dev? If so, should I refactor an old
> email of mine and post a draft here for more tab-specific comments?
Please do so.
On the technical level: would a 'tab' map to a section handled by its
own sitemap? Just an idea.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
Tab Issues (was: Re: Need todo list for Cocoon transition)
Posted by Diana Shannon <sh...@apache.org>.
Now, tabs.
<diana>
4. Tab decisions (IMO these could wait).
</diana?
<steven>
you will need to add some tabs, I believe, but that's dead simple.
</steven>
<david>
As far as i can tell, tabs do not work yet.
</david>
<konstantin>
They work, but you have to perform some hacky things to make them behave
as
expected...
</konstantin>
Issues
1. Steven, you used the term "dead simple." Maybe dead simple to
implement, but IMHO deciding what content goes under what tab should be
decided on cocoon-dev. If so, IMHO it needs to be proposed on
cocoon-dev. Is anyone working on a proposal? I started assessing this
when I first started looking at the Cocoon web site and its doc issues.
Should we create a draft proposal here on Forrest and then post it for
comments and feedback on cocoon-dev? If so, should I refactor an old
email of mine and post a draft here for more tab-specific comments?
2. Bert, do you have time to fix the so-called hacky things, or should
we wait to get feedback from cocoon-dev about what to do about the
overall skin issue first?
Diana
Re: Skin issues (was: Re: Need todo list for Cocoon transition)
Posted by David Crossley <cr...@indexgeo.com.au>.
Steven Noels wrote:
> Diana Shannon wrote:
>
> <snip/>
>
> > Maybe it's a goal of Forrest to have a uniform xml.apache.org web site
> > -- but -- have you actually checked with other xml.apache.org projects?
> > Do they consider it a goal? Are all of them represented here? Have all
> > of them been participating in the skin development process?
> >
> > It's seems to me, no. Am I wrong, lurkers?
>
> The bert skin is based on the original proposal of Stefano which has
> been discussed into much length on general@xml.apache.org during the
> last months of 2001, IIRC. We know it will be a long time before
> actually showing something based on the discussions held in that time,
> but there was a consensus, then:
>
> * we need a common design
> * of course, it should be optional, you always have projects who like to
> go their own way (I'm not too keen on this, because it breaks the
> consistency of the xml.apache.org website, but that's life)
> * the design Stefano proposed that time seemed the way to go forward
>
> > Strategically speaking, as a friend of Forrest, you need to:
> > 1. Update the Forrest site to show the Bert skin
>
> I could be doing this next week, although I prefer to wait until Forrest
> is ready to easily support remote doco building.
>
> Aside: anyone strong feelings against including Forrest on the
> xml.apache.org main site?
We should have it there ASAP, after bert skin is happening.
I still think that we are not yet ready with content (e.g the
dreams document is very vague). Anyway, that can improve later.
Let us get it out there, so that we can foster some ownership.
> > 2. Contact all xml.apache.org projects and ask them to comment on the
> > skin. In other words, allow them to influence the design so that they
> > "invest" and "own" the final result. Otherwise, I fear it will be
> > perceived as a top-down approach which will have limited success.
>
> see above
>
> It's not that I don't want to go into that discussion anymore, but as
> Stefano stated some time ago, we should move away from the skins
> discussion and focus on core issues:
>
> * remote doco building
> * DTD documentation
> * graphs
> * PDF generation
> * cross-project information (i.e. the main xml.apache.org site)
>
> I want to tackle some of those so that others hopefully pick them up and
> enhance them - most of this stuff isn't too hard to implement but we
> seem to prefer talking about it on this list instead of getting things done.
The reason that there has been a lot of talking, is that
many of us were (and still are) confused as to the role and
the scope of Forrest. It seems that the original discussion
must have happened off-list or still be in the founders' heads.
> <snip/>
>
> > Above all, let's *not* let skin issues hold up our being able to use all
> > the other great stuff Forrest has to offer!
>
> Yep. Do not understand me wrong: I love talking about these issues, but
> the better model currently seems to me to actually put something into
> CVS and discuss/change that afterwards.
Yes, this is the best way. Some concrete stuff will help us
to shape and evolve Forrest ... and hopefully encourage more
contributers and thence new committers. There are too few
active troops at the moment.
--David
Re: Skin issues (was: Re: Need todo list for Cocoon transition)
Posted by Steven Noels <st...@outerthought.org>.
Diana Shannon wrote:
<snip/>
> Maybe it's a goal of Forrest to have a uniform xml.apache.org web site
> -- but -- have you actually checked with other xml.apache.org projects?
> Do they consider it a goal? Are all of them represented here? Have all
> of them been participating in the skin development process?
>
> It's seems to me, no. Am I wrong, lurkers?
The bert skin is based on the original proposal of Stefano which has
been discussed into much length on general@xml.apache.org during the
last months of 2001, IIRC. We know it will be a long time before
actually showing something based on the discussions held in that time,
but there was a consensus, then:
* we need a common design
* of course, it should be optional, you always have projects who like to
go their own way (I'm not too keen on this, because it breaks the
consistency of the xml.apache.org website, but that's life)
* the design Stefano proposed that time seemed the way to go forward
> Strategically speaking, as a friend of Forrest, you need to:
> 1. Update the Forrest site to show the Bert skin
I could be doing this next week, although I prefer to wait until Forrest
is ready to easily support remote doco building.
Aside: anyone strong feelings against including Forrest on the
xml.apache.org main site?
> 2. Contact all xml.apache.org projects and ask them to comment on the
> skin. In other words, allow them to influence the design so that they
> "invest" and "own" the final result. Otherwise, I fear it will be
> perceived as a top-down approach which will have limited success.
see above
It's not that I don't want to go into that discussion anymore, but as
Stefano stated some time ago, we should move away from the skins
discussion and focus on core issues:
* remote doco building
* DTD documentation
* graphs
* PDF generation
* cross-project information (i.e. the main xml.apache.org site)
I want to tackle some of those so that others hopefully pick them up and
enhance them - most of this stuff isn't too hard to implement but we
seem to prefer talking about it on this list instead of getting things done.
<snip/>
> Above all, let's *not* let skin issues hold up our being able to use all
> the other great stuff Forrest has to offer!
Yep. Do not understand me wrong: I love talking about these issues, but
the better model currently seems to me to actually put something into
CVS and discuss/change that afterwards.
Cheers,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
Skin issues (was: Re: Need todo list for Cocoon transition)
Posted by Diana Shannon <sh...@apache.org>.
Please, let's continue:
<diana>
1. Skin has to be decided by cocoon-dev, right? If so, shouldn't we get
this process started on cocoon-dev?
</diana>
<steven>
yep (and please refrain from building your own skin ;-)
IMO, the 'bert' skin is the obvious choice right now
</steven>
<david>
Why do you say that? I imagine that many projects will not
want the default Forrest skin and will want to use their own.
I do understand that for this stage of Forrest it would be
far easier to just stick with the default.
Has Forrest yet decided how broad is the scope of its skin?
I am confused as to the intention. Is the skin just for
Forrest home and community docs, or does it apply to all
projects?
</david>
<steven>
Both easiness and consistency, IMO. One of the goals of Forrest is to
have a uniform xml.apache.org website. The skinning system is mainly
targeted towards projects externally to xml.apache.org.
</steven>
<konstantin>
I like the 'bert' skin and I think that there will be no problems in
cocoon-dev if we use it for Cocoon site & docs.
</konstantin>
Maybe it's a goal of Forrest to have a uniform xml.apache.org web
site -- but -- have you actually checked with other xml.apache.org
projects? Do they consider it a goal? Are all of them represented here?
Have all of them been participating in the skin development process?
It's seems to me, no. Am I wrong, lurkers?
Strategically speaking, as a friend of Forrest, you need to:
1. Update the Forrest site to show the Bert skin
2. Contact all xml.apache.org projects and ask them to comment on the
skin. In other words, allow them to influence the design so that they
"invest" and "own" the final result. Otherwise, I fear it will be
perceived as a top-down approach which will have limited success.
3. Give cocoon-dev the option to vote on the following:
a. using Forrest skin on the condition that it can be improved over
time with their feedback
b. allow Cocoon to continue using an "updated" (based on new dtds,
etc.) old skin, with the plan to change the new Forrest skin, once it
has been enhanced. Yes, I realize this is going to take some work, and
will delay our efforts, but it can be done.
Maybe Konstantin's right, that Cocoon will adopt the Bert skin with "no
problems". Still, I'd rather confirm this with a vote (preceeded, of
course, by a strong and convincing proposal about the "best" approach,
i.e. option (a) above.)
Above all, let's *not* let skin issues hold up our being able to use all
the other great stuff Forrest has to offer!
Diana
Re: Branch Issues (was: Re: Need todo list for Cocoon transition)
Posted by Steven Noels <st...@outerthought.org>.
Diana Shannon wrote:
> Suggestion:
> Would it easier/faster -- for starters -- to test automated Forrest
> builds against Cocoon release branch only? If we're only talking about
> the web site (and not distro doc builds) we don't need separate branch
> builds via Forrest.
Definitely, although I'll try to make branch-building possible too.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
Branch Issues (was: Re: Need todo list for Cocoon transition)
Posted by Diana Shannon <sh...@apache.org>.
Next, branches:
<diana>
How do we address the differences between different versions of Cocoon
in branches. Currently docs builds in HEAD are created with Cocoon 2.1;
release uses 2.0.3. Will these differences affect Forrest-generated
builds? Remember, we still need to have users be able to build their own
docs from local cvs repositories based on multiple branches, don't we?
</diana>
<steven>
there's no concept of CVS branches inside project.xtarget right now, but
it should be possible to add those and run Forrest across both
branches - something we should add to the forrest.xconf descriptor, I
guess.
</steven>
Suggestion:
Would it easier/faster -- for starters -- to test automated Forrest
builds against Cocoon release branch only? If we're only talking about
the web site (and not distro doc builds) we don't need separate branch
builds via Forrest.
Diana
Re: Need todo list for Cocoon transition
Posted by Steven Noels <st...@outerthought.org>.
Diana Shannon wrote:
> I'm still a little confused about what exactly remains for Cocoon to
> begin its transition to Forrest. Can someone please enlighten me by
> helping to complete a todo list? I thought David and I had trudged
> through most of the hard work already. I feel good about the state of
> the docs. I'm psyched to get going with Forrest and its promise. So,
> what remains to do?
>
> Seems to me:
>
> 1. Skin has to be decided by cocoon-dev, right? If so, shouldn't we get
> this process started on cocoon-dev?
yep (and please refrain from building your own skin ;-)
IMO, the 'bert' skin is the obvious choice right now
> 2. Build targets need to be added to address all of Cocoon's current
> builds.
well... I have been planning (and postponing) to clean up the current
forrest build environment and *finally* support remote project building
- unfortunately, I will not be able to work on this before next week.
Given that, there shouldn't be any adaptation necessary anymore.
> 3. Cocoon CVS needs some revisions
> - add forrest.xgump
> - add build facilities and targets
> - ? Is the Forrest CVS adapting to Cocoon CVS structure or vice versa?
I checked the src/documentation structure of current Cocoon CVS and it
seems pretty well shaped up for Forrest remote project building.
> 4. Tab decisions (IMO these could wait).
you will need to add some tabs, I believe, but that's dead simple.
> 5. URISpace decisions (IMO these could also wait)
yep
> ... what else?
>
> Issues
> How do we address the differences between different versions of Cocoon
> in branches. Currently docs builds in HEAD are created with Cocoon 2.1;
> release uses 2.0.3. Will these differences affect Forrest-generated
> builds? Remember, we still need to have users be able to build their own
> docs from local cvs repositories based on multiple branches, don't we?
there's no concept of CVS branches inside project.xtarget right now, but
it should be possible to add those and run Forrest across both branches
- something we should add to the forrest.xconf descriptor, I guess.
> Target Date
> I'd like to complete this before 2.1 beta of Cocoon. Is it feasible?
When is that beta 'planned'?
> Even if we can't automate the web site updates yet, we could still
> transition to the necessary architecture, correct? Honestly, I'd prefer
> to continue with manual updates until we arrive at a comfort zone with
> all transition issues.
As I said, the documents seem pretty well shaped up. When do you plan to
make the transition to v11 DTDs? Or would you still be using the upgrade
XSLT?
> Thanks for your guidance.
I need to get Forrest in a better shape by the end of next week for a
customer - so hopefully I'll be able to add this remote project building
support 'RSN'(tm).
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org