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
