You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ross Gardler <rg...@apache.org> on 2007/04/10 23:08:52 UTC
0.8RC1 Failure
0.8RC1 fails to build site-author with errors such as the following in
broken-links.xml:
<link message="Could not find component for role:
[org.apache.cocoon.components.modules.input.InputModule/defaults]
(Key='org.apache.cocoon.components.modules.input.InputModule/defaults')"
uri="procedures/release/How_to_release.html">
<referrer uri="linkmap.html"/>
</link>
a seed-sample works just fine.
Going to bed - will pick up tomorrow.
Ross
Re: plugins deployment problem (Was: 0.8RC1 Failure)
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
>> Updated my local copy with 'svn up' of forrest/site/plugins
>> and listed them. In the table below:
>> Section 1 ... f.a.o/plugins/
>> Section 2 ... f.a.o/plugins/0.8/
>> Section 3 ... f.a.o/plugins/0.7/
...
> Imagine this scenarion:
>
> Section 3 ... f.a.o/plugins/0.9/
Sorry that should read
Section 4 ... f.a.o/plugins/0.9/
Ross
Re: plugins deployment problem (Was: 0.8RC1 Failure)
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2007-04-11 at 16:42 +0100, Ross Gardler wrote:
...
> I tried doing the dispatcher plugin, but its site will not build and
> therefore it cannot deploy.
Yeah, my fault, thanks for spotting it. Should be fixed now.
> I did do the themes plugin.
thanks.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: plugins deployment problem (Was: 0.8RC1 Failure)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
>
> >>There should be no need to rebuild the release since we are not bundling
> >>plugin sources and only committers can deploy plugins (i.e. those using
> >>SVN head)
> >
> >It is a change to trunk, so the svn tag, which is done
> >later in the process, will be in the wrong place.
> >As long as there are no further vital changes (which will
> >cause an RC2 to be necessary) then the tag can be
> >made to the relevant revision.
>
> I've not updated the tag, I'll leave that for you David as the RM.
The tag is done later, and only if there is a successful
outcome from the testing and the release vote.
-David
Re: plugins deployment problem (Was: 0.8RC1 Failure)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
...
>> Does this sound right to you. If so I'll update the deployment scripts.
>
> Please do it.
Done.
I'm in the process of deploying all the released plugins with this new
script to ensure everything is set up correctly.
I tried doing the dispatcher plugin, but its site will not build and
therefore it cannot deploy. I don't have the time (or inclination) to
fix it so perhaps someone active on dispatcher can look at it.
I did do the themes plugin.
I've not done any other whiteboard plugins.
>> There should be no need to rebuild the release since we are not bundling
>> plugin sources and only committers can deploy plugins (i.e. those using
>> SVN head)
>
> It is a change to trunk, so the svn tag, which is done
> later in the process, will be in the wrong place.
> As long as there are no further vital changes (which will
> cause an RC2 to be necessary) then the tag can be
> made to the relevant revision.
I've not updated the tag, I'll leave that for you David as the RM.
Ross
Re: plugins deployment problem (Was: 0.8RC1 Failure)
Posted by Ross Gardler <rg...@apache.org>.
CFAS Webmaster wrote:
> Curiosity - I retrieved SVN version 527170 on or around the 10th and was
> able to build the CFAS site correctly. I just did an 'svn up' which is
> 527470, but nothing changed.
> Did any of the changes along this thread introduce any changes to the
> SVN repository?
No.
Ross
Re: plugins deployment problem (Was: 0.8RC1 Failure)
Posted by David Crossley <cr...@apache.org>.
CFAS Webmaster wrote:
> David Crossley wrote:
> >David Crossley wrote:
> >>CFAS Webmaster wrote:
> >>
> >>>Curiosity - I retrieved SVN version 527170 on or around the 10th and was
> >>>able to build the CFAS site correctly. I just did an 'svn up' which is
> >>>527470, but nothing changed.
> >
> >The ASF has a single public repository for all
> >projects. The revision identifiers are a global
> >sequential number. So some other project would have
> >made a change.
> >
> Understood, I was just checking.
Okay. To keep an eye on what commits have happened
one can subscribe to our svn@ list or browse an archive.
http://forrest.apache.org/mail-lists.html
> >>>Did any of the changes along this thread introduce any changes to the
> >>>SVN repository?
> >>>
> >>>I'm really looking forward to updating the site to use dispatcher too!
> >>>
> >>Thanks, that helps. However, it is the actual
> >>release candidate package that we need testing,
> >>not the SVN trunk.
>
> The results on building the CFAS website are the same with RC1 as
> distributed and SVN trunk, revision 527170. Everything works as
> expected. I've been using SVN trunk for building since a little after
> 0.7 was released.
>
> Thanks!
> -Paul
Fantastic. Thanks for your interest.
-David
Re: plugins deployment problem (Was: 0.8RC1 Failure)
Posted by CFAS Webmaster <we...@cfas.org>.
David Crossley wrote:
> David Crossley wrote:
>
>> CFAS Webmaster wrote:
>>
>>> Curiosity - I retrieved SVN version 527170 on or around the 10th and was
>>> able to build the CFAS site correctly. I just did an 'svn up' which is
>>> 527470, but nothing changed.
>>>
>
> The ASF has a single public repository for all
> projects. The revision identifiers are a global
> sequential number. So some other project would have
> made a change.
>
> -David
>
Understood, I was just checking.
>>> Did any of the changes along this thread introduce any changes to the
>>> SVN repository?
>>>
>>> I'm really looking forward to updating the site to use dispatcher too!
>>>
>> Thanks, that helps. However, it is the actual
>> release candidate package that we need testing,
>> not the SVN trunk.
>>
>> -David
The results on building the CFAS website are the same with RC1 as
distributed and SVN trunk, revision 527170. Everything works as
expected. I've been using SVN trunk for building since a little after
0.7 was released.
Thanks!
-Paul
Re: plugins deployment problem (Was: 0.8RC1 Failure)
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> CFAS Webmaster wrote:
> > Curiosity - I retrieved SVN version 527170 on or around the 10th and was
> > able to build the CFAS site correctly. I just did an 'svn up' which is
> > 527470, but nothing changed.
The ASF has a single public repository for all
projects. The revision identifiers are a global
sequential number. So some other project would have
made a change.
-David
> > Did any of the changes along this thread introduce any changes to the
> > SVN repository?
> >
> > I'm really looking forward to updating the site to use dispatcher too!
>
> Thanks, that helps. However, it is the actual
> release candidate package that we need testing,
> not the SVN trunk.
>
> -David
Re: plugins deployment problem (Was: 0.8RC1 Failure)
Posted by David Crossley <cr...@apache.org>.
CFAS Webmaster wrote:
> Curiosity - I retrieved SVN version 527170 on or around the 10th and was
> able to build the CFAS site correctly. I just did an 'svn up' which is
> 527470, but nothing changed.
>
> Did any of the changes along this thread introduce any changes to the
> SVN repository?
>
> I'm really looking forward to updating the site to use dispatcher too!
Thanks, that helps. However, it is the actual
release candidate package that we need testing,
not the SVN trunk.
-David
Re: plugins deployment problem (Was: 0.8RC1 Failure)
Posted by CFAS Webmaster <we...@cfas.org>.
Curiosity - I retrieved SVN version 527170 on or around the 10th and was
able to build the CFAS site correctly. I just did an 'svn up' which is
527470, but nothing changed.
Did any of the changes along this thread introduce any changes to the
SVN repository?
I'm really looking forward to updating the site to use dispatcher too!
Thanks!
-Paul
David Crossley wrote:
> Ross Gardler wrote:
>
>> David Crossley wrote:
>>
>>> I am try to determine the state of plugins deployment.
>>> It seems that some are wrong.
>>>
>>> Updated my local copy with 'svn up' of forrest/site/plugins
>>> and listed them. In the table below:
>>> Section 1 ... f.a.o/plugins/
>>> Section 2 ... f.a.o/plugins/0.8/
>>> Section 3 ... f.a.o/plugins/0.7/
>>>
>>> I tried to compare the dates and presence of plugins
>>> in Section 1 with those in Section 2. (Not looked at 3.)
>>> See the Column #1 and Column #2.
>>>
>>> Here is how i think plugins work. Please correct me if wrong.
>>>
>>> The term "versioned" means that its name ends in say "-0.2".
>>> They would specify an exact version in their forrest.properties
>>> Otherwise it is "unversioned".
>>>
>>> I am only considering "unversioned" at this stage.
>>>
>>> For users of 0.8 release, if present in Section 2
>>> then use it, otherwise try Section 1.
>>>
>> That is how I understand it too.
>>
>> However, your comments about the purpose section 2 are incorrect.
>>
>> Imagine this scenarion:
>>
>> Section 3 ... f.a.o/plugins/0.9/
>>
>
> That is:
> Section 4 ... f.a.o/plugins/0.9/
>
> Ah, good idea. I should have tried to think ahead
> one more version.
>
> Also i was reviewing the actual (some mis-deployed) files,
> whereas you are explaining how it should work. Thanks,
> it is clearer now.
>
> I pulled these comments out of the plugins/build.xml
> to clarify these terms.
>
> release
> Put versioned plugin in the ${forrest.version} directory.
> The filename gets "-${plugin-version}" appended.
>
> deploy
> Put unversioned plugin in the top-level directory.
>
> So are we saying that "deploy" should also put the
> unversioned plugin in the ${forrest.version} directory.
> We deploy more often that we release.
>
>
>> Plugin A has been updated to take advantage of 0.9, but has not been
>> released
>>
>> Plugin B has still only uses features of 0.8, but has a deployed update
>> (not released)
>>
>> Plugin A should be found in Section 2, but a newer copy will be found in
>> section 1 and section 4. This latter copy will have the 0.9 updates.
>>
>> Plugin B should be found in Section 2 with an identical copy in section 1
>>
>> A user on Forrest 0.8 will get plugin A from Section 2 and plugin B from
>> section 2
>>
>> A user on Forrest 0.9 will get plugin A from section 4 and plugin B from
>> section 2
>>
>> So why do we need section 1? It was a fallback, if someone has, for
>> example, Forrest 0.8 but requests a plugin that only exists for Forrest
>> 0.9+ it will get the one from section 1 in the hope that it will work.
>>
>> This last step is, perhaps, redundant.
>>
>
> Leave it in until we know.
>
>
>>> Lets try some examples ...
>>>
>>> o.a.f...core
>>> It is not present in Section 2 so gets used from
>>> Section 1 (the most recent deployment).
>>> Correct.
>>> However it is way out-of-date. So will break for 0.8 users.
>>>
>> Core is whiteboard so was not deployed in my recent updates of plugins.
>> Once it is deployed this will be solved.
>>
>
> These need to be either deployed much more often,
> or not deployed at all and get developers to
> use SVN.
>
> As it is currently, 0.8 users will get a horrid message
> when they try the Dispatcher that everyone has been
> talking about. I tried it as part of my release testing.
>
>
>>> o.a.f...dispatcher
>>> It is present in Section 2 so that gets used.
>>> There is a newer one in Section 1 which will not be used.
>>> Incorrect.
>>> Both are way out-of-date. So will break for 0.8 users.
>>>
>> Ditto (whiteboard)
>>
>>
>>> o.a.f...PhotoGallery
>>> It is present in Section 2 so that gets used.
>>> There is a newer one in Section 1 which will not be used.
>>> Incorrect.
>>>
>> This is a released plugin and so should be in section 2 as well. I did
>> deploy this, along with other released plugins, so this is an error in
>> the deployment. The new version should be in section 2 as well as section 1.
>>
>
> Ah, that explains the differences.
>
>
>>> o.a.f...projectInfo
>>> It is present in Section 2 so that gets used.
>>> There is an equal date one in Section 1 which will not be used.
>>> Incorrect. When it is later updated, a newer one
>>> in Section 1 would never get used. This error happened
>>> yesterday.
>>>
>> No, it should be section 2 that is used:
>>
>> Forrest 0.8, get the latest unversioned plugin that is known to be for
>> 0.8, i.e. section 2
>>
>> This is the same probelm as above, incorrect deployment script.
>>
>>
>>> So it seems to me that all unversioned plugins need
>>> to be removed from Section 2 and only go back there
>>> if new functionality is added in 0.9-dev that means
>>> a break in 0.8 compatibility.
>>>
>> I don't see it like that. I believe that we need to fix the deployment
>> of plugins so that they go into the correct plugins/0.x directory as
>> well as the root directory all will be well.
>>
>
> It all makes sense now that you explain that
> the deployment is wrong.
>
> Deja vu. I remember this discussion a couple
> of times. Neither us nor anyone else managed to
> implement it.
>
>
>> The fallback position of the root directory could cause problems in the
>> future though. If someone updates a 0.8 version of a plugin and deploys
>> it will currently overwrite the 0.9 version in the root directory. This
>> also needs to be fixed in the deploy target.
>>
>> (new mantra, switch plugin downloads to Ivy)
>>
>
> Definitely.
>
>
>> Does this sound right to you. If so I'll update the deployment scripts.
>>
>
> Please do it.
>
>
>> There should be no need to rebuild the release since we are not bundling
>> plugin sources and only committers can deploy plugins (i.e. those using
>> SVN head)
>>
>
> It is a change to trunk, so the svn tag, which is done
> later in the process, will be in the wrong place.
> As long as there are no further vital changes (which will
> cause an RC2 to be necessary) then the tag can be
> made to the relevant revision.
>
> People can continue with their testing.
>
> -David
>
Re: plugins deployment problem (Was: 0.8RC1 Failure)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >
> >I am try to determine the state of plugins deployment.
> >It seems that some are wrong.
> >
> >Updated my local copy with 'svn up' of forrest/site/plugins
> >and listed them. In the table below:
> >Section 1 ... f.a.o/plugins/
> >Section 2 ... f.a.o/plugins/0.8/
> >Section 3 ... f.a.o/plugins/0.7/
> >
> >I tried to compare the dates and presence of plugins
> >in Section 1 with those in Section 2. (Not looked at 3.)
> >See the Column #1 and Column #2.
> >
> >Here is how i think plugins work. Please correct me if wrong.
> >
> >The term "versioned" means that its name ends in say "-0.2".
> >They would specify an exact version in their forrest.properties
> >Otherwise it is "unversioned".
> >
> >I am only considering "unversioned" at this stage.
> >
> >For users of 0.8 release, if present in Section 2
> >then use it, otherwise try Section 1.
>
> That is how I understand it too.
>
> However, your comments about the purpose section 2 are incorrect.
>
> Imagine this scenarion:
>
> Section 3 ... f.a.o/plugins/0.9/
That is:
Section 4 ... f.a.o/plugins/0.9/
Ah, good idea. I should have tried to think ahead
one more version.
Also i was reviewing the actual (some mis-deployed) files,
whereas you are explaining how it should work. Thanks,
it is clearer now.
I pulled these comments out of the plugins/build.xml
to clarify these terms.
release
Put versioned plugin in the ${forrest.version} directory.
The filename gets "-${plugin-version}" appended.
deploy
Put unversioned plugin in the top-level directory.
So are we saying that "deploy" should also put the
unversioned plugin in the ${forrest.version} directory.
We deploy more often that we release.
> Plugin A has been updated to take advantage of 0.9, but has not been
> released
>
> Plugin B has still only uses features of 0.8, but has a deployed update
> (not released)
>
> Plugin A should be found in Section 2, but a newer copy will be found in
> section 1 and section 4. This latter copy will have the 0.9 updates.
>
> Plugin B should be found in Section 2 with an identical copy in section 1
>
> A user on Forrest 0.8 will get plugin A from Section 2 and plugin B from
> section 2
>
> A user on Forrest 0.9 will get plugin A from section 4 and plugin B from
> section 2
>
> So why do we need section 1? It was a fallback, if someone has, for
> example, Forrest 0.8 but requests a plugin that only exists for Forrest
> 0.9+ it will get the one from section 1 in the hope that it will work.
>
> This last step is, perhaps, redundant.
Leave it in until we know.
> >Lets try some examples ...
> >
> >o.a.f...core
> >It is not present in Section 2 so gets used from
> >Section 1 (the most recent deployment).
> >Correct.
> >However it is way out-of-date. So will break for 0.8 users.
>
> Core is whiteboard so was not deployed in my recent updates of plugins.
> Once it is deployed this will be solved.
These need to be either deployed much more often,
or not deployed at all and get developers to
use SVN.
As it is currently, 0.8 users will get a horrid message
when they try the Dispatcher that everyone has been
talking about. I tried it as part of my release testing.
> >o.a.f...dispatcher
> >It is present in Section 2 so that gets used.
> >There is a newer one in Section 1 which will not be used.
> >Incorrect.
> >Both are way out-of-date. So will break for 0.8 users.
>
> Ditto (whiteboard)
>
> >o.a.f...PhotoGallery
> >It is present in Section 2 so that gets used.
> >There is a newer one in Section 1 which will not be used.
> >Incorrect.
>
> This is a released plugin and so should be in section 2 as well. I did
> deploy this, along with other released plugins, so this is an error in
> the deployment. The new version should be in section 2 as well as section 1.
Ah, that explains the differences.
> >o.a.f...projectInfo
> >It is present in Section 2 so that gets used.
> >There is an equal date one in Section 1 which will not be used.
> >Incorrect. When it is later updated, a newer one
> >in Section 1 would never get used. This error happened
> >yesterday.
>
> No, it should be section 2 that is used:
>
> Forrest 0.8, get the latest unversioned plugin that is known to be for
> 0.8, i.e. section 2
>
> This is the same probelm as above, incorrect deployment script.
>
> >So it seems to me that all unversioned plugins need
> >to be removed from Section 2 and only go back there
> >if new functionality is added in 0.9-dev that means
> >a break in 0.8 compatibility.
>
> I don't see it like that. I believe that we need to fix the deployment
> of plugins so that they go into the correct plugins/0.x directory as
> well as the root directory all will be well.
It all makes sense now that you explain that
the deployment is wrong.
Deja vu. I remember this discussion a couple
of times. Neither us nor anyone else managed to
implement it.
> The fallback position of the root directory could cause problems in the
> future though. If someone updates a 0.8 version of a plugin and deploys
> it will currently overwrite the 0.9 version in the root directory. This
> also needs to be fixed in the deploy target.
>
> (new mantra, switch plugin downloads to Ivy)
Definitely.
> Does this sound right to you. If so I'll update the deployment scripts.
Please do it.
> There should be no need to rebuild the release since we are not bundling
> plugin sources and only committers can deploy plugins (i.e. those using
> SVN head)
It is a change to trunk, so the svn tag, which is done
later in the process, will be in the wrong place.
As long as there are no further vital changes (which will
cause an RC2 to be necessary) then the tag can be
made to the relevant revision.
People can continue with their testing.
-David
Re: plugins deployment problem (Was: 0.8RC1 Failure)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> David Crossley wrote:
>> David Crossley wrote:
>>> David Crossley wrote:
>>>> Found it. Looking in the logs after the first failed
>>>> 'forrest run'
>>>> site-author/build/webapp/WEB-INF/logs/error.log
>>>> showed that there was a problem with
>>>> {defaults:bugtracking-url} in the projectInfo plugin
>>>> input.xmap
>>>>
>>>> Comparing the downloaded plugin
>>>> $FORREST_HOME/build/plugins/o.a.f...projectInfo/input.xmap
>>>> with the trunk plugin input.xmap shows that this is old
>>>> and therefore the projectInfo plugin was not
>>>> properly publicly deployed.
>>>>
>>>> I just deployed that plugin again. Now we need
>>>> to wait for the automated rsync to publish.
>>>>
>>>> I will monitor and test when it is ready.
>>> The site was updated at about 20 mins past the hour.
>>>
>>> The plugin was deployed to f.a.o/plugins/
>>>
>>> However, when i do the site-author forrest run
>>> it tries to get the plugin from f.a.o/plugins/0.8/
>>> and so it gets an old copy.
>>>
>>> I am going to manually svn copy the plugin from
>>> forrest/site/plugins/o.a.f...projectInfo.zip to
>>> forrest/site/plugins/0.8/o.a.f...projectInfo.zip
>> Yipee ... "Welcome to Apache Forrest".
>>
>> Now people can get on with testing.
>
> That temporary fix worked. See below.
>
> I am try to determine the state of plugins deployment.
> It seems that some are wrong.
>
> Updated my local copy with 'svn up' of forrest/site/plugins
> and listed them. In the table below:
> Section 1 ... f.a.o/plugins/
> Section 2 ... f.a.o/plugins/0.8/
> Section 3 ... f.a.o/plugins/0.7/
>
> I tried to compare the dates and presence of plugins
> in Section 1 with those in Section 2. (Not looked at 3.)
> See the Column #1 and Column #2.
>
> Here is how i think plugins work. Please correct me if wrong.
>
> The term "versioned" means that its name ends in say "-0.2".
> They would specify an exact version in their forrest.properties
> Otherwise it is "unversioned".
>
> I am only considering "unversioned" at this stage.
>
> For users of 0.8 release, if present in Section 2
> then use it, otherwise try Section 1.
That is how I understand it too.
However, your comments about the purpose section 2 are incorrect.
Imagine this scenarion:
Section 3 ... f.a.o/plugins/0.9/
Plugin A has been updated to take advantage of 0.9, but has not been
released
Plugin B has still only uses features of 0.8, but has a deployed update
(not released)
Plugin A should be found in Section 2, but a newer copy will be found in
section 1 and section 4. This latter copy will have the 0.9 updates.
Plugin B should be found in Section 2 with an identical copy in section 1
A user on Forrest 0.8 will get plugin A from Section 2 and plugin B from
section 2
A user on Forrest 0.9 will get plugin A from section 4 and plugin B from
section 2
So why do we need section 1? It was a fallback, if someone has, for
example, Forrest 0.8 but requests a plugin that only exists for Forrest
0.9+ it will get the one from section 1 in the hope that it will work.
This last step is, perhaps, redundant.
> Lets try some examples ...
>
> o.a.f...core
> It is not present in Section 2 so gets used from
> Section 1 (the most recent deployment).
> Correct.
> However it is way out-of-date. So will break for 0.8 users.
Core is whiteboard so was not deployed in my recent updates of plugins.
Once it is deployed this will be solved.
> o.a.f...dispatcher
> It is present in Section 2 so that gets used.
> There is a newer one in Section 1 which will not be used.
> Incorrect.
> Both are way out-of-date. So will break for 0.8 users.
Ditto (whiteboard)
> o.a.f...PhotoGallery
> It is present in Section 2 so that gets used.
> There is a newer one in Section 1 which will not be used.
> Incorrect.
This is a released plugin and so should be in section 2 as well. I did
deploy this, along with other released plugins, so this is an error in
the deployment. The new version should be in section 2 as well as section 1.
> o.a.f...projectInfo
> It is present in Section 2 so that gets used.
> There is an equal date one in Section 1 which will not be used.
> Incorrect. When it is later updated, a newer one
> in Section 1 would never get used. This error happened
> yesterday.
No, it should be section 2 that is used:
Forrest 0.8, get the latest unversioned plugin that is known to be for
0.8, i.e. section 2
This is the same probelm as above, incorrect deployment script.
> So it seems to me that all unversioned plugins need
> to be removed from Section 2 and only go back there
> if new functionality is added in 0.9-dev that means
> a break in 0.8 compatibility.
I don't see it like that. I believe that we need to fix the deployment
of plugins so that they go into the correct plugins/0.x directory as
well as the root directory all will be well.
The fallback position of the root directory could cause problems in the
future though. If someone updates a 0.8 version of a plugin and deploys
it will currently overwrite the 0.9 version in the root directory. This
also needs to be fixed in the deploy target.
(new mantra, switch plugin downloads to Ivy)
Does this sound right to you. If so I'll update the deployment scripts.
There should be no need to rebuild the release since we are not bundling
plugin sources and only committers can deploy plugins (i.e. those using
SVN head)
Ross
Re: plugins deployment problem (Was: 0.8RC1 Failure)
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> David Crossley wrote:
> > David Crossley wrote:
> > > Found it. Looking in the logs after the first failed
> > > 'forrest run'
> > > site-author/build/webapp/WEB-INF/logs/error.log
> > > showed that there was a problem with
> > > {defaults:bugtracking-url} in the projectInfo plugin
> > > input.xmap
> > >
> > > Comparing the downloaded plugin
> > > $FORREST_HOME/build/plugins/o.a.f...projectInfo/input.xmap
> > > with the trunk plugin input.xmap shows that this is old
> > > and therefore the projectInfo plugin was not
> > > properly publicly deployed.
> > >
> > > I just deployed that plugin again. Now we need
> > > to wait for the automated rsync to publish.
> > >
> > > I will monitor and test when it is ready.
> >
> > The site was updated at about 20 mins past the hour.
> >
> > The plugin was deployed to f.a.o/plugins/
> >
> > However, when i do the site-author forrest run
> > it tries to get the plugin from f.a.o/plugins/0.8/
> > and so it gets an old copy.
> >
> > I am going to manually svn copy the plugin from
> > forrest/site/plugins/o.a.f...projectInfo.zip to
> > forrest/site/plugins/0.8/o.a.f...projectInfo.zip
>
> Yipee ... "Welcome to Apache Forrest".
>
> Now people can get on with testing.
That temporary fix worked. See below.
I am try to determine the state of plugins deployment.
It seems that some are wrong.
Updated my local copy with 'svn up' of forrest/site/plugins
and listed them. In the table below:
Section 1 ... f.a.o/plugins/
Section 2 ... f.a.o/plugins/0.8/
Section 3 ... f.a.o/plugins/0.7/
I tried to compare the dates and presence of plugins
in Section 1 with those in Section 2. (Not looked at 3.)
See the Column #1 and Column #2.
Here is how i think plugins work. Please correct me if wrong.
The term "versioned" means that its name ends in say "-0.2".
They would specify an exact version in their forrest.properties
Otherwise it is "unversioned".
I am only considering "unversioned" at this stage.
For users of 0.8 release, if present in Section 2
then use it, otherwise try Section 1.
An unversioned plugin would only exist in Section 2
if it is not yet taking advantage of newest development.
So it needs to be tied to 0.8 release.
Lets try some examples ...
o.a.f...core
It is not present in Section 2 so gets used from
Section 1 (the most recent deployment).
Correct.
However it is way out-of-date. So will break for 0.8 users.
o.a.f...dispatcher
It is present in Section 2 so that gets used.
There is a newer one in Section 1 which will not be used.
Incorrect.
Both are way out-of-date. So will break for 0.8 users.
o.a.f...PhotoGallery
It is present in Section 2 so that gets used.
There is a newer one in Section 1 which will not be used.
Incorrect.
o.a.f...projectInfo
It is present in Section 2 so that gets used.
There is an equal date one in Section 1 which will not be used.
Incorrect. When it is later updated, a newer one
in Section 1 would never get used. This error happened
yesterday.
So it seems to me that all unversioned plugins need
to be removed from Section 2 and only go back there
if new functionality is added in 0.9-dev that means
a break in 0.8 compatibility.
---------------------------------------
Column #1 ... Date
N = Newer
E = Equal
O = Older
- = Not in the 0.8 directory
* = Old plugin name
Column #2 ... When updated
R = Recent - Updated in last two weeks
O = Old - older than two weeks
A = Ancient - older than four months
Section 1 ... f.a.o/plugins/
* 226356 Mar 31 2005 org.apache.forrest.plugin.htmlArea.zip
O O 32220 Nov 17 2005 org.apache.forrest.plugin.input.Daisy.zip
- R 122652 Apr 10 08:57 org.apache.forrest.plugin.input.OpenOffice.org.zip
N R 2628205 Apr 11 11:53 org.apache.forrest.plugin.input.PhotoGallery.zip
- R 54493 Apr 10 08:57 org.apache.forrest.plugin.input.dtdx.zip
- R 77346 Apr 10 08:57 org.apache.forrest.plugin.input.excel.zip
- R 56573 Apr 10 08:57 org.apache.forrest.plugin.input.feeder.zip
- R 33866 Apr 11 11:53 org.apache.forrest.plugin.input.glossary.zip
E R 34541 Apr 10 08:57 org.apache.forrest.plugin.input.listLocations.zip
- A 29665 Aug 4 2005 org.apache.forrest.plugin.input.logs.zip
E R 123039 Apr 11 12:28 org.apache.forrest.plugin.input.projectInfo.zip
E A 24114 Feb 11 2006 org.apache.forrest.plugin.input.serverStatus.zip
* 52360 Jun 17 2005 org.apache.forrest.plugin.input.simplified-docbook.zip
- R 57230 Apr 10 08:57 org.apache.forrest.plugin.input.simplifiedDocbook.zip
- R 114805 Apr 10 08:57 org.apache.forrest.plugin.input.wiki.zip
- A 31701 Jun 27 2005 org.apache.forrest.plugin.internal.IMSManifest.zip
N A 191135 Sep 13 2006 org.apache.forrest.plugin.internal.dispatcher.zip
* 324850 Aug 4 2005 org.apache.forrest.plugin.internal.view.zip
- A 28646 Jan 4 2005 org.apache.forrest.plugin.logs.zip
- A 1550949 Aug 4 2005 org.apache.forrest.plugin.output.Chart.zip
- R 31399 Apr 10 08:57 org.apache.forrest.plugin.output.POD.zip
- R 60597 Apr 10 08:57 org.apache.forrest.plugin.output.Text.zip
- A 458112 Aug 4 2005 org.apache.forrest.plugin.output.htmlArea.zip
- R 26499 Apr 10 08:57 org.apache.forrest.plugin.output.inputModule.zip
- R 26411 Apr 10 08:57 org.apache.forrest.plugin.output.pdf.zip
O A 23672 Aug 4 2005 org.apache.forrest.plugin.output.voice.zip
* 86065 Apr 8 2005 org.apache.forrest.plugin.view.zip
- A 197862 Jul 27 2006 org.apache.forrest.themes.core.zip
R 8989 Apr 11 12:28 plugins.xml
R 10802 Apr 11 11:53 whiteboard-plugins.xml
Section 2 ... f.a.o/plugins/0.8/
32220 Feb 14 2006 org.apache.forrest.plugin.input.Daisy-0.1-dev.zip
32220 Apr 10 08:56 org.apache.forrest.plugin.input.Daisy.zip
2725350 Feb 24 2006 org.apache.forrest.plugin.input.PhotoGallery-0.2.zip
2725350 Feb 24 2006 org.apache.forrest.plugin.input.PhotoGallery.zip
27045 Feb 11 2006 org.apache.forrest.plugin.input.listLocations-0.2.zip
27045 Apr 10 08:56 org.apache.forrest.plugin.input.listLocations.zip
47540 Feb 14 2006 org.apache.forrest.plugin.input.projectInfo-0.2-dev.zip
123039 Apr 11 12:41 org.apache.forrest.plugin.input.projectInfo.zip
24114 Feb 11 2006 org.apache.forrest.plugin.input.serverStatus-0.1.zip
24114 Apr 10 08:56 org.apache.forrest.plugin.input.serverStatus.zip
159530 Feb 11 2006 org.apache.forrest.plugin.internal.dispatcher.zip
93454 Mar 5 18:20 org.apache.forrest.plugin.output.solr-0.1.zip
25944 Feb 14 2006 org.apache.forrest.plugin.output.voice-0.1-dev.zip
25944 Feb 14 2006 org.apache.forrest.plugin.output.voice.zip
Section 3 ... f.a.o/plugins/0.7/
121128 Jun 17 2005 org.apache.forrest.plugin.input.OpenOffice.org-0.1.zip
121128 Apr 10 08:56 org.apache.forrest.plugin.input.OpenOffice.org.zip
2729209 Jun 23 2005 org.apache.forrest.plugin.input.PhotoGallery-0.1.zip
2729209 Apr 10 08:56 org.apache.forrest.plugin.input.PhotoGallery.zip
51823 Jun 27 2005 org.apache.forrest.plugin.input.dtdx-0.1.zip
51823 Apr 10 08:56 org.apache.forrest.plugin.input.dtdx.zip
74613 Apr 10 08:56 org.apache.forrest.plugin.input.excel-0.3.zip
74613 Apr 10 08:56 org.apache.forrest.plugin.input.excel.zip
53581 Jun 27 2005 org.apache.forrest.plugin.input.feeder-0.1.zip
53581 Apr 10 08:56 org.apache.forrest.plugin.input.feeder.zip
28544 Nov 11 2005 org.apache.forrest.plugin.input.listLocations-0.1.zip
28544 Apr 10 08:56 org.apache.forrest.plugin.input.listLocations.zip
29665 Aug 4 2005 org.apache.forrest.plugin.input.logs-0.1-dev.zip
29665 Apr 10 08:56 org.apache.forrest.plugin.input.logs.zip
34194 Nov 13 2005 org.apache.forrest.plugin.input.projectInfo-0.1.zip
34194 Nov 14 2005 org.apache.forrest.plugin.input.projectInfo.zip
52360 Jun 9 2005 org.apache.forrest.plugin.input.simplified-docbook-0.1.zip
52484 Jun 17 2005 org.apache.forrest.plugin.input.simplifiedDocbook-0.1.zip
52484 Apr 10 08:56 org.apache.forrest.plugin.input.simplifiedDocbook.zip
108486 Jun 27 2005 org.apache.forrest.plugin.input.wiki-0.1.zip
108486 Apr 10 08:56 org.apache.forrest.plugin.input.wiki.zip
31701 Jun 27 2005 org.apache.forrest.plugin.internal.IMSManifest-0.1.zip
324850 Aug 4 2005 org.apache.forrest.plugin.internal.view-0.1-dev.zip
1550949 Apr 10 08:56 org.apache.forrest.plugin.output.Chart-0.1.zip
1550949 Apr 10 08:56 org.apache.forrest.plugin.output.Chart.zip
28933 Nov 13 2005 org.apache.forrest.plugin.output.POD-0.1.zip
28933 Apr 10 08:56 org.apache.forrest.plugin.output.POD.zip
56367 Nov 13 2005 org.apache.forrest.plugin.output.Text-0.1.zip
56367 Apr 10 08:56 org.apache.forrest.plugin.output.Text.zip
458112 Apr 10 08:56 org.apache.forrest.plugin.output.htmlArea-0.1.zip
458112 Apr 10 08:56 org.apache.forrest.plugin.output.htmlArea.zip
23715 Jul 13 2005 org.apache.forrest.plugin.output.pdf-0.1.zip
23715 Apr 10 08:56 org.apache.forrest.plugin.output.pdf.zip
-------------------------------
Re: plugins deployment problem (Was: 0.8RC1 Failure)
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> David Crossley wrote:
> > Found it. Looking in the logs after the first failed
> > 'forrest run'
> > site-author/build/webapp/WEB-INF/logs/error.log
> > showed that there was a problem with
> > {defaults:bugtracking-url} in the projectInfo plugin
> > input.xmap
> >
> > Comparing the downloaded plugin
> > $FORREST_HOME/build/plugins/o.a.f...projectInfo/input.xmap
> > with the trunk plugin input.xmap shows that this is old
> > and therefore the projectInfo plugin was not
> > properly publicly deployed.
> >
> > I just deployed that plugin again. Now we need
> > to wait for the automated rsync to publish.
> >
> > I will monitor and test when it is ready.
>
> The site was updated at about 20 mins past the hour.
>
> The plugin was deployed to f.a.o/plugins/
>
> However, when i do the site-author forrest run
> it tries to get the plugin from f.a.o/plugins/0.8/
> and so it gets an old copy.
>
> I am going to manually svn copy the plugin from
> forrest/site/plugins/o.a.f...projectInfo.zip to
> forrest/site/plugins/0.8/o.a.f...projectInfo.zip
Yipee ... "Welcome to Apache Forrest".
Now people can get on with testing.
-David
plugins deployment problem (Was: 0.8RC1 Failure)
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> Found it. Looking in the logs after the first failed
> 'forrest run'
> site-author/build/webapp/WEB-INF/logs/error.log
> showed that there was a problem with
> {defaults:bugtracking-url} in the projectInfo plugin
> input.xmap
>
> Comparing the downloaded plugin
> $FORREST_HOME/build/plugins/o.a.f...projectInfo/input.xmap
> with the trunk plugin input.xmap shows that this is old
> and therefore the projectInfo plugin was not
> properly publicly deployed.
>
> I just deployed that plugin again. Now we need
> to wait for the automated rsync to publish.
>
> I will monitor and test when it is ready.
The site was updated at about 20 mins past the hour.
The plugin was deployed to f.a.o/plugins/
However, when i do the site-author forrest run
it tries to get the plugin from f.a.o/plugins/0.8/
and so it gets an old copy.
I am going to manually svn copy the plugin from
forrest/site/plugins/o.a.f...projectInfo.zip to
forrest/site/plugins/0.8/o.a.f...projectInfo.zip
Will report back after 20 mins past again.
-David
Re: 0.8RC1 Failure
Posted by David Crossley <cr...@apache.org>.
Found it. Looking in the logs after the first failed
'forrest run'
site-author/build/webapp/WEB-INF/logs/error.log
showed that there was a problem with
{defaults:bugtracking-url} in the projectInfo plugin
input.xmap
Comparing the downloaded plugin
$FORREST_HOME/build/plugins/o.a.f...projectInfo/input.xmap
with the trunk plugin input.xmap shows that this is old
and therefore the projectInfo plugin was not
properly publicly deployed.
I just deployed that plugin again. Now we need
to wait for the automated rsync to publish.
I will monitor and test when it is ready.
-David
Re: 0.8RC1 Failure
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> 0.8RC1 fails to build site-author with errors such as the following in
> broken-links.xml:
>
> <link message="Could not find component for role:
> [org.apache.cocoon.components.modules.input.InputModule/defaults]
> (Key='org.apache.cocoon.components.modules.input.InputModule/defaults')"
> uri="procedures/release/How_to_release.html">
> <referrer uri="linkmap.html"/>
> </link>
>
> a seed-sample works just fine.
Hmmm, i get the same.
Unpack the package,
cd site-author
forrest run
... get the error that you describe.
However when i stop the 'forrest run' and
immediately start it again, then all is well.
Similarly with 'forrest site' ...
Remove it,
Unpack the package,
cd site-author
forrest site
... get the error that you describe on every doc.
However when it is immediately done again,
then all is well.
-David