You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by David Crossley <cr...@apache.org> on 2005/11/12 03:38:28 UTC
deployed plugins with wrong version number
Bringing over from the user list:
Re: Installation/Internal Server Error Cocoon related?
...
David Crossley wrote:
> Ross Gardler wrote:
> > David Crossley wrote:
> > >
> > >Ross, i wonder if this is because of the plugins revamp that
> > >we are doing today. I deployed some plugins, and they probably
> > >did not have the version number bumped to 0.8
> > >
> > >What do you reckon?
> >
> > It is possible, although I don't think so since it is reported as
> > working with forrest run and site, the problem is only in webapp. We
> > need to do some testing locally to confirm this though.
> >
> > I'm going to bed very soon. If you have the time could you install a 0.7
> > version of Forrest and try and reproduce.
>
> Yep, that is probably it. I can confirm the failure
> that Chris reported. Thanks.
>
> I will report back when it is fixed.
Ross, i needed to go back to 2 months ago. The projectInfo
plugin started to use the locationmap at r278579
and we must have accidently deployed it as version 0.7
rather than as 0.8-dev
Anyway, i redeployed that old input.projectInfo and
redeployed the output.POD and output.Text plugins from
yesterday.
Then the site-author build worked fine using forrest-0.7
Then re-deploying the version 0.8 of the projectInfo
plugins caused the error again.
-David
Re: deployed plugins with wrong version number
Posted by Ross Gardler <rg...@apache.org>.
I'll come back to this when I have time, but the proverbil has hit the
fan and I'm going on holiday ;-)
In the meantime, if you want to just go ahead with your solution, that
is fine by me as I see no problems with your approach, it's just it's
different from my own.
Ross
David Crossley wrote:
> Ross Gardler wrote:
>
>>David Crossley wrote:
>>
>>>David Crossley wrote:
>>>
>>>
>>>>Reviving this old thread from Nov 26, 2005.
>>>>
>>>>At today's ForrestFriday we discussed the issue
>>>>again. See the IRC logfile.
>>>>http://svn.apache.org/repos/asf/forrest/events/forrest-friday/20060210-log.txt
>>>>
>>>>Ross, i figured out some of my confusion about this.
>>>>I did not realise that there are two separate targets
>>>>"deploy" and "release".
>>>>
>>>>Please review this revision which i think fixes the deployment.
>>>>http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/build.xml?rev=376952&r1=376890&r2=376952&diff_format=h
>>>>
>>>>Next we need to investigate the fetch-plugin stuff,
>>>>then deploy all relevant plugins.
>>>
>>>
>>>Hmmm, i reckon that this is not going to work.
>>>For example, the projectInfo input plugin.
>>>
>>>We recently upgraded that plugin to use locationmap,
>>>so now it is bound to forrest-0.8 version.
>>>That is now deployed as the top-level unversioned
>>>f.a.o/plugins/o.a.f.plugin.projectInfo.zip
>>>
>>>So now forrest-0.7 users need to specifically declare
>>>the versioned plugin which forrest-0.7 will find at
>>>f.a.o/plugins/0.7/o.a.f.plugin.projectInfo-0.1.zip
>>>
>>>Perhaps the following arrangement would be better:
>>>
>>>Deploy both versioned and unversioned plugins to
>>>the respective forrest.version directory, i.e.
>>>
>>>f.a.o/plugins/0.7/o.a.f.plugin.projectInfo.zip
>>>f.a.o/plugins/0.7/o.a.f.plugin.projectInfo-0.1.zip
>>>...
>>>f.a.o/plugins/0.8/o.a.f.plugin.projectInfo.zip
>>>f.a.o/plugins/0.8/o.a.f.plugin.projectInfo-0.2.zip
>>>...
>>>
>>>Don't use the top-level f.a.o/plugins/*.zip at all.
>>
>>But this would mean deploying the unversioned copy to all the forrest
>>core version directories, i.e. 0.7, 0.8. 0.9, 0.10 etc.
>
>
> The approach that i was considering is to put an
> unversioned copy relevant to each specific version.
>
> Take the example of the whiteboard "Chart" plugin.
> Its forrest.version is 0.7 so it will not appear
> in the 0.8 plugins directory.
>
> The plugin's build.xml (or the main plugins.xml)
> tells forrest the relevant forrest.version number
> and it would go directly to get the unversioned
> plugin from f.a.o/plugins/0.7/...Chart.zip
>
> Users of 0.8 would still get that plugins/0.7/...
> because that is what is specified in plugins.xml
>
>
>>A little reminder form our IRC chat:
>>
>>The idea of the unversioned plugins is that a user can say "I want to be
>>at the cutting edge of this particular plugin, but I don't care about
>>the core of Forrest".
>
>
> Perhaps i am missing the point, but i do not see
> the benefit. If the cutting-edge is for a higher
> version of Forrest, then it will most likely be
> broken for their use. That is the reason that we
> raised its forrest.version number.
>
>
>>These people specify an unversioned plugin, Forrest will download the
>>latest development version of the plugin (it is intended that a later
>>version of Forrest will automatically upgrade this plugin to keep the
>>user on the cutting edge).
>>
>>So, a user using Forrest 0.7 will get the same version the projectInfo
>>plugin as one using Forrest 0.8 (i.e. from the top level directory).
>>But, what if the latest dev plugin doesn't work with their installed
>>version of Forrest?
>
>
> Users of 0.7 will get an obscure error message
> something to do with "Could not read directory: .../webapp"
> or something like that, caused by trying to use a
> locationmap-enabled plugin, i.e. specific to 0.8
>
>
>>At this point Forrest should report that they need to upgrade Forrest in
>>order to work with the latest projectInfo plugin, or they will need to
>>downgrade the plugin version to the last version working with 0.7
>>(eventually Forrest should ask what to do and update the properties file
>>appropriately).
>
>
> How would Forrest know the cause of the problem?
>
> -David
>
>
>>We can do swanky things like list the improvements in Forrest and the
>>Plugin to help users make this decision, but that is for later too.
>>
>>Ross
>
>
>
Re: deployed plugins with wrong version number
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >David Crossley wrote:
> >
> >>Reviving this old thread from Nov 26, 2005.
> >>
> >>At today's ForrestFriday we discussed the issue
> >>again. See the IRC logfile.
> >>http://svn.apache.org/repos/asf/forrest/events/forrest-friday/20060210-log.txt
> >>
> >>Ross, i figured out some of my confusion about this.
> >>I did not realise that there are two separate targets
> >>"deploy" and "release".
> >>
> >>Please review this revision which i think fixes the deployment.
> >>http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/build.xml?rev=376952&r1=376890&r2=376952&diff_format=h
> >>
> >>Next we need to investigate the fetch-plugin stuff,
> >>then deploy all relevant plugins.
> >
> >
> >Hmmm, i reckon that this is not going to work.
> >For example, the projectInfo input plugin.
> >
> >We recently upgraded that plugin to use locationmap,
> >so now it is bound to forrest-0.8 version.
> >That is now deployed as the top-level unversioned
> >f.a.o/plugins/o.a.f.plugin.projectInfo.zip
> >
> >So now forrest-0.7 users need to specifically declare
> >the versioned plugin which forrest-0.7 will find at
> >f.a.o/plugins/0.7/o.a.f.plugin.projectInfo-0.1.zip
> >
> >Perhaps the following arrangement would be better:
> >
> >Deploy both versioned and unversioned plugins to
> >the respective forrest.version directory, i.e.
> >
> >f.a.o/plugins/0.7/o.a.f.plugin.projectInfo.zip
> >f.a.o/plugins/0.7/o.a.f.plugin.projectInfo-0.1.zip
> >...
> >f.a.o/plugins/0.8/o.a.f.plugin.projectInfo.zip
> >f.a.o/plugins/0.8/o.a.f.plugin.projectInfo-0.2.zip
> >...
> >
> >Don't use the top-level f.a.o/plugins/*.zip at all.
>
> But this would mean deploying the unversioned copy to all the forrest
> core version directories, i.e. 0.7, 0.8. 0.9, 0.10 etc.
The approach that i was considering is to put an
unversioned copy relevant to each specific version.
Take the example of the whiteboard "Chart" plugin.
Its forrest.version is 0.7 so it will not appear
in the 0.8 plugins directory.
The plugin's build.xml (or the main plugins.xml)
tells forrest the relevant forrest.version number
and it would go directly to get the unversioned
plugin from f.a.o/plugins/0.7/...Chart.zip
Users of 0.8 would still get that plugins/0.7/...
because that is what is specified in plugins.xml
> A little reminder form our IRC chat:
>
> The idea of the unversioned plugins is that a user can say "I want to be
> at the cutting edge of this particular plugin, but I don't care about
> the core of Forrest".
Perhaps i am missing the point, but i do not see
the benefit. If the cutting-edge is for a higher
version of Forrest, then it will most likely be
broken for their use. That is the reason that we
raised its forrest.version number.
> These people specify an unversioned plugin, Forrest will download the
> latest development version of the plugin (it is intended that a later
> version of Forrest will automatically upgrade this plugin to keep the
> user on the cutting edge).
>
> So, a user using Forrest 0.7 will get the same version the projectInfo
> plugin as one using Forrest 0.8 (i.e. from the top level directory).
> But, what if the latest dev plugin doesn't work with their installed
> version of Forrest?
Users of 0.7 will get an obscure error message
something to do with "Could not read directory: .../webapp"
or something like that, caused by trying to use a
locationmap-enabled plugin, i.e. specific to 0.8
> At this point Forrest should report that they need to upgrade Forrest in
> order to work with the latest projectInfo plugin, or they will need to
> downgrade the plugin version to the last version working with 0.7
> (eventually Forrest should ask what to do and update the properties file
> appropriately).
How would Forrest know the cause of the problem?
-David
> We can do swanky things like list the improvements in Forrest and the
> Plugin to help users make this decision, but that is for later too.
>
> Ross
Re: deployed plugins with wrong version number
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> David Crossley wrote:
>
>>Reviving this old thread from Nov 26, 2005.
>>
>>At today's ForrestFriday we discussed the issue
>>again. See the IRC logfile.
>>http://svn.apache.org/repos/asf/forrest/events/forrest-friday/20060210-log.txt
>>
>>Ross, i figured out some of my confusion about this.
>>I did not realise that there are two separate targets
>>"deploy" and "release".
>>
>>Please review this revision which i think fixes the deployment.
>>http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/build.xml?rev=376952&r1=376890&r2=376952&diff_format=h
>>
>>Next we need to investigate the fetch-plugin stuff,
>>then deploy all relevant plugins.
>
>
> Hmmm, i reckon that this is not going to work.
> For example, the projectInfo input plugin.
>
> We recently upgraded that plugin to use locationmap,
> so now it is bound to forrest-0.8 version.
> That is now deployed as the top-level unversioned
> f.a.o/plugins/o.a.f.plugin.projectInfo.zip
>
> So now forrest-0.7 users need to specifically declare
> the versioned plugin which forrest-0.7 will find at
> f.a.o/plugins/0.7/o.a.f.plugin.projectInfo-0.1.zip
>
> Perhaps the following arrangement would be better:
>
> Deploy both versioned and unversioned plugins to
> the respective forrest.version directory, i.e.
>
> f.a.o/plugins/0.7/o.a.f.plugin.projectInfo.zip
> f.a.o/plugins/0.7/o.a.f.plugin.projectInfo-0.1.zip
> ...
> f.a.o/plugins/0.8/o.a.f.plugin.projectInfo.zip
> f.a.o/plugins/0.8/o.a.f.plugin.projectInfo-0.2.zip
> ...
>
> Don't use the top-level f.a.o/plugins/*.zip at all.
But this would mean deploying the unversioned copy to all the forrest
core version directories, i.e. 0.7, 0.8. 0.9, 0.10 etc.
A little reminder form our IRC chat:
The idea of the unversioned plugins is that a user can say "I want to be
at the cutting edge of this particular plugin, but I don't care about
the core of Forrest".
These people specify an unversioned plugin, Forrest will download the
latest development version of the plugin (it is intended that a later
version of Forrest will automatically upgrade this plugin to keep the
user on the cutting edge).
So, a user using Forrest 0.7 will get the same version the projectInfo
plugin as one using Forrest 0.8 (i.e. from the top level directory).
But, what if the latest dev plugin doesn't work with their installed
version of Forrest?
At this point Forrest should report that they need to upgrade Forrest in
order to work with the latest projectInfo plugin, or they will need to
downgrade the plugin version to the last version working with 0.7
(eventually Forrest should ask what to do and update the properties file
appropriately).
We can do swanky things like list the improvements in Forrest and the
Plugin to help users make this decision, but that is for later too.
Ross
Re: deployed plugins with wrong version number
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> Reviving this old thread from Nov 26, 2005.
>
> At today's ForrestFriday we discussed the issue
> again. See the IRC logfile.
> http://svn.apache.org/repos/asf/forrest/events/forrest-friday/20060210-log.txt
>
> Ross, i figured out some of my confusion about this.
> I did not realise that there are two separate targets
> "deploy" and "release".
>
> Please review this revision which i think fixes the deployment.
> http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/build.xml?rev=376952&r1=376890&r2=376952&diff_format=h
>
> Next we need to investigate the fetch-plugin stuff,
> then deploy all relevant plugins.
Hmmm, i reckon that this is not going to work.
For example, the projectInfo input plugin.
We recently upgraded that plugin to use locationmap,
so now it is bound to forrest-0.8 version.
That is now deployed as the top-level unversioned
f.a.o/plugins/o.a.f.plugin.projectInfo.zip
So now forrest-0.7 users need to specifically declare
the versioned plugin which forrest-0.7 will find at
f.a.o/plugins/0.7/o.a.f.plugin.projectInfo-0.1.zip
Perhaps the following arrangement would be better:
Deploy both versioned and unversioned plugins to
the respective forrest.version directory, i.e.
f.a.o/plugins/0.7/o.a.f.plugin.projectInfo.zip
f.a.o/plugins/0.7/o.a.f.plugin.projectInfo-0.1.zip
...
f.a.o/plugins/0.8/o.a.f.plugin.projectInfo.zip
f.a.o/plugins/0.8/o.a.f.plugin.projectInfo-0.2.zip
...
Don't use the top-level f.a.o/plugins/*.zip at all.
To enable forrest-0.7 to continue to operate, use a
f.a.o/plugins/.htaccess file to enable Apache HTTP
Server to re-direct to f.a.o/plugins/0.7/*.zip
Also need re-direct for the old f.a.o/plugins/0.8-dev/
to f.a.o/plugins/0.8/
That would cause breakage for users of 0.8-dev
who do not have an up-to-date SVN trunk. If they
cannot update to head, then they can specify a
direct versioned plugin.
Would that be sufficient?
-David
Re: deployed plugins with wrong version number
Posted by David Crossley <cr...@apache.org>.
Reviving this old thread from Nov 26, 2005.
At today's ForrestFriday we discussed the issue
again. See the IRC logfile.
http://svn.apache.org/repos/asf/forrest/events/forrest-friday/20060210-log.txt
Ross, i figured out some of my confusion about this.
I did not realise that there are two separate targets
"deploy" and "release".
Please review this revision which i think fixes the deployment.
http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/build.xml?rev=376952&r1=376890&r2=376952&diff_format=h
Next we need to investigate the fetch-plugin stuff,
then deploy all relevant plugins.
-David
Re: deployed plugins with wrong version number
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>David Crossley wrote:
>>
>>>Ross Gardler wrote:
>>>
>>>>David Crossley wrote:
>>>>
>>>>>Ross Gardler wrote:
>>>>>
>>>>>>David Crossley wrote:
>>>>>>
>>>>>>
>>>>>>>I wonder if it is because there in no "unversioned"
>>>>>>>plugin in the 0.7 directory. At 0.7 release time
>>>>>>>perhaps we needed to copy the unversioned ones there too.
>>>>>>
>>>>>>Yes, that will be it, I'll look into this ASAP. Thanks.
>>>>>
>>>>>I tried this by:
>>>>>cd forrest-site/plugins/0.7/
>>>>>svn cp org.apache.forrest.plugin.input.projectInfo-0.1.zip
>>>>>org.apache.forrest.plugin.input.projectInfo.zip
>>>>>svn commit
>>>>>... then waited for the hourly cronjob to 'svn update' our site.
>>>>>
>>>>>Then tried again with forrest_07 and same problem that was
>>>>>reported above.
>>>>>
>>>>>I noticed that it is trying to retrieve:
>>>>>http://forrest.apache.org/plugins//org.apache.forrest.plugin.input.projectInfo.zip
>>>>>... perhaps needs /0.7/ in that empty space.
>>>>
>>>>Thanks David. I'll have to dig into the build files to see what is
>>>>happening. Probaboly won't have the time until the end of the week at
>>>>the earliest.
>>>
>>>I did this today and it now works for me with forrest_07_branch.
>>>
>>>---------------
>>>[main]$ svn diff var/pluginlist2fetch.xsl
>>>Index: var/pluginlist2fetch.xsl
>>>===================================================================
>>>--- var/pluginlist2fetch.xsl (revision 329512)
>>>+++ var/pluginlist2fetch.xsl (working copy)
>>>@@ -46,7 +46,7 @@
>>> <target name="fetch-unversioned-plugin"
>>> unless="versioned-plugin.present">
>>> <echo>Versioned plugin unavailable, trying to get versionless
>>> plugin...</echo>
>>> <get verbose="true" usetimestamp="true" ignoreerrors="true">
>>>- <xsl:attribute name="src"><xsl:value-of
>>>select="plugin[@name=$plugin-name]/@url" />/<xsl:value-of
>>>select="$plugin-name" />.zip</xsl:attribute>
>>>+ <xsl:attribute name="src"><xsl:value-of
>>>select="plugin[@name=$plugin-name]/@url" />/<xsl:value-of
>>>select="$forrest-version" />/<xsl:value-of select="$plugin-name"
>>>/>.zip</xsl:attribute>
>>>---------------
>>>
>>>So our plugin deployment process needs to put a copy
>>>of the plugin into the specific version directory, e.g.
>>>in plugins/0.8-dev/ and we need to manually add them to
>>>the plugins/0.7/ directory.
>>
>>Thanks for looking at this David, as you guessed I have not had the time
>>yet. Something does not ring true for me with this patch.
>
>
> It is only part of the solution. The rest is the changes
> to the deployment process that we arrived at below.
> See above, i also temporarily placed an unversioned copy
> of the projectInfo plugin into plugins/0.7/ but it doesn't
> yet have copies of the rest.
>
>
>>I don't have
>>the time to check the main plugin build.xml right now, but from memory:
>>
>>What happens when a plugin is deployed is that a versioned copy is put
>>into the a specific Forrest directory (i.e. 0.8) and an unversioned copy
>>is put into the root distirbution directory (I *think* that I prevented
>>a versioned copy with a "-dev" version number going into the versioned
>>Forrest directory).
>>
>>This means that a versioned copy is in the correct versioned forrest
>>directory (identified in the plugins own build.xml). Remember that a
>>plugin is intended to work with a minimum version of Forrest. The
>>unversioned copy of the plugin was plaved in the root unversioned
>>directory in order to minimise the number of copies that we need on the
>>server.
>
>
> So are we saying below at [A] that we won't worry about
> duplication? I am fine with that.
Yes
>>The assumption was that people using development versions of
>>plugins will be using development versions of Forrest.
>>
>>This is not a good assumption.
>
>
> [A]
>
>
>>>Perhaps we then don't need the unversioned plugins at
>>>the plugins/ directory, rather only have them in the
>>>specific sub-directory.
>>
>>Yes, and I think the version resolving gode needs to be refined as well.
>>Currently, if a plugin works in 0.7 and 0.8-dev I think we need a copy
>>of the plugin in both subdirectories as the plugin resolving code does
>>not check other directories. What we need is for the loading code to
>>look first in the correct Forrest version directory, then in the
>>previous version and so on until it finds the right version of the plugin.
>>
>>We can hack this solutoin together in the ANT scripts fairly easily
>>(time allowing ;-)
Done. Very easy once my son gets me up in the middles of the night (poor
blighter has a horrible cold)
WARNING
I have only tested this on one plugin (I'm going back to bed now, Zeph
is sound asleep again):
Added:
forrest/site/plugins/0.8-dev/org.apache.forrest.plugin.input.projectInfo.zip
(with props)
> I made an Issue to remind us.
> http://issues.apache.org/jira/browse/FOR-742
>
> On a related issue, what happens at release time?
> I suppose that we just do an 'svn copy' of 0.8-dev
> directory to 0.8 directory and create a 0.9-dev dir.
That sounds right.
> The other steps about incrementing the release number
> in plugins/build.xml is already noted in etc/RELEASE_PROCESS.txt
There is also this code in the plugins/build.xml file:
<if>
<contains string="${forrest.version}" substring="0.7"/>
<then>
<property name="docsVersion" value="0_70"/>
</then>
<else>
<if>
<contains string="${forrest.version}" substring="0.8"/>
<then>
<property name="docsVersion" value="0_80"/>
</then>
<else>
<!-- FIXME: the docs version number should be derived
programmatically from the forrest.version in use
(see http://issues.apache.org/jira/browse/FOR-535) -->
<fail message="Trying to deploy plugin docs to an unkown
version of Forrest. Please update the plugins build file."/>
</else>
</if>
</else>
</if>
This is necessary because the docs directories are not the same as the
version number.
(I have not updated the release process - need sleep)
> Also i notice that there is already a f.a.o/plugins/0.8/
> Perhaps that was an accident by specifying 0.8
> rather than 0.8-dev in a plugins.xml entry.
The forrest.version is no longer taken from plugins.xml, it is taken
from the plugin build.xml file (need to generate plugins.xml from
build.xml, there's an issue for that somewhere).
The two plugins that have been deployed into 0.8 now have the correct
value for forrest.version property.
The plugins/build.xml, which provides a fallback value for the property
also had 0.8 in it, I fixed that too.
> Do we need to remove that and redeploy them?
projectInfo was already redeployed so no problem with that one. The
voice one should be redeployed, but my local version has some
modifications that are unfinished so I can't redeploy now, perhaps
someone can do it after an "svn up".
>>For the future I want to create a new plugin resolving mechanism that
>>loads plugins at runtime rather than at startup. We need to modify the
>>Locationmap somthing like this:
>>
>><match pattern="plugin.xmap.*">
>> <location src="{project:tmp}/{1}/>
>> <install src="http://f.a.o/plugins/0.8/{1}/>
>> <install src="http://f.a.o/plugins/0.7/{1}/>
>> <location src="{forrest:plugin.fallback}/error.pluginNotFound.xmap"/>
>></match>
>>
>>The we can dynamically install features at run time rather than at
>>startup. We would even be able to add plugins at runtime.
>>
>>Still, I digress. I've added these comments to
>>http://issues.apache.org/jira/browse/FOR-741 (good to see JIRA forcing
>>me to add a component)
>>
>>
>>>>In the meantime we need to advise users to add a version number as you
>>>>discovered.
>>>
>>>I am surprised that we are not getting more pleas for
>>>help from users of the 0.7 projectInfo plugin.
>>
>>It will only affect new users. Those who have the plugin installed
>>already will not be trying to retrieve it, therefore no problem emerges..
>
>
> However if anyone does a "build clean" then they
> are going to hit this trouble, e.g. people with their
> own Java customisations or someone doing 'build clean'
> when they don't really need to. Stylesheet and sitemap
> changes don't need to.
This problem will be solved by "use plugins inplace" [1] and/or
"override plugin installation directory" [2]. I've linked both to "allow
dynamic loading of plugin" [3]
[1] http://issues.apache.org/jira/browse/FOR-388
[2] http://issues.apache.org/jira/browse/FOR-462
[3] http://issues.apache.org/jira/browse/FOR-741
Seems like the issue tracker has everything covered, now if only the
tracker could actually implement the solutions ;-)
(mind you with Tim's willingness to grab issues from the tracker we are
going that way - we need more "Tims")
Ross
Re: deployed plugins with wrong version number
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >>David Crossley wrote:
> >>>Ross Gardler wrote:
> >>>>David Crossley wrote:
> >>>>
> >>>>>I wonder if it is because there in no "unversioned"
> >>>>>plugin in the 0.7 directory. At 0.7 release time
> >>>>>perhaps we needed to copy the unversioned ones there too.
> >>>>
> >>>>Yes, that will be it, I'll look into this ASAP. Thanks.
> >>>
> >>>I tried this by:
> >>>cd forrest-site/plugins/0.7/
> >>>svn cp org.apache.forrest.plugin.input.projectInfo-0.1.zip
> >>>org.apache.forrest.plugin.input.projectInfo.zip
> >>>svn commit
> >>>... then waited for the hourly cronjob to 'svn update' our site.
> >>>
> >>>Then tried again with forrest_07 and same problem that was
> >>>reported above.
> >>>
> >>>I noticed that it is trying to retrieve:
> >>>http://forrest.apache.org/plugins//org.apache.forrest.plugin.input.projectInfo.zip
> >>>... perhaps needs /0.7/ in that empty space.
> >>
> >>Thanks David. I'll have to dig into the build files to see what is
> >>happening. Probaboly won't have the time until the end of the week at
> >>the earliest.
> >
> >I did this today and it now works for me with forrest_07_branch.
> >
> >---------------
> >[main]$ svn diff var/pluginlist2fetch.xsl
> >Index: var/pluginlist2fetch.xsl
> >===================================================================
> >--- var/pluginlist2fetch.xsl (revision 329512)
> >+++ var/pluginlist2fetch.xsl (working copy)
> >@@ -46,7 +46,7 @@
> > <target name="fetch-unversioned-plugin"
> > unless="versioned-plugin.present">
> > <echo>Versioned plugin unavailable, trying to get versionless
> > plugin...</echo>
> > <get verbose="true" usetimestamp="true" ignoreerrors="true">
> >- <xsl:attribute name="src"><xsl:value-of
> >select="plugin[@name=$plugin-name]/@url" />/<xsl:value-of
> >select="$plugin-name" />.zip</xsl:attribute>
> >+ <xsl:attribute name="src"><xsl:value-of
> >select="plugin[@name=$plugin-name]/@url" />/<xsl:value-of
> >select="$forrest-version" />/<xsl:value-of select="$plugin-name"
> >/>.zip</xsl:attribute>
> >---------------
> >
> >So our plugin deployment process needs to put a copy
> >of the plugin into the specific version directory, e.g.
> >in plugins/0.8-dev/ and we need to manually add them to
> >the plugins/0.7/ directory.
>
> Thanks for looking at this David, as you guessed I have not had the time
> yet. Something does not ring true for me with this patch.
It is only part of the solution. The rest is the changes
to the deployment process that we arrived at below.
See above, i also temporarily placed an unversioned copy
of the projectInfo plugin into plugins/0.7/ but it doesn't
yet have copies of the rest.
> I don't have
> the time to check the main plugin build.xml right now, but from memory:
>
> What happens when a plugin is deployed is that a versioned copy is put
> into the a specific Forrest directory (i.e. 0.8) and an unversioned copy
> is put into the root distirbution directory (I *think* that I prevented
> a versioned copy with a "-dev" version number going into the versioned
> Forrest directory).
>
> This means that a versioned copy is in the correct versioned forrest
> directory (identified in the plugins own build.xml). Remember that a
> plugin is intended to work with a minimum version of Forrest. The
> unversioned copy of the plugin was plaved in the root unversioned
> directory in order to minimise the number of copies that we need on the
> server.
So are we saying below at [A] that we won't worry about
duplication? I am fine with that.
> The assumption was that people using development versions of
> plugins will be using development versions of Forrest.
>
> This is not a good assumption.
[A]
> >Perhaps we then don't need the unversioned plugins at
> >the plugins/ directory, rather only have them in the
> >specific sub-directory.
>
> Yes, and I think the version resolving gode needs to be refined as well.
> Currently, if a plugin works in 0.7 and 0.8-dev I think we need a copy
> of the plugin in both subdirectories as the plugin resolving code does
> not check other directories. What we need is for the loading code to
> look first in the correct Forrest version directory, then in the
> previous version and so on until it finds the right version of the plugin.
>
> We can hack this solutoin together in the ANT scripts fairly easily
> (time allowing ;-)
I made an Issue to remind us.
http://issues.apache.org/jira/browse/FOR-742
On a related issue, what happens at release time?
I suppose that we just do an 'svn copy' of 0.8-dev
directory to 0.8 directory and create a 0.9-dev dir.
The other steps about incrementing the release number
in plugins/build.xml is already noted in etc/RELEASE_PROCESS.txt
Also i notice that there is already a f.a.o/plugins/0.8/
Perhaps that was an accident by specifying 0.8
rather than 0.8-dev in a plugins.xml entry.
Do we need to remove that and redeploy them?
> For the future I want to create a new plugin resolving mechanism that
> loads plugins at runtime rather than at startup. We need to modify the
> Locationmap somthing like this:
>
> <match pattern="plugin.xmap.*">
> <location src="{project:tmp}/{1}/>
> <install src="http://f.a.o/plugins/0.8/{1}/>
> <install src="http://f.a.o/plugins/0.7/{1}/>
> <location src="{forrest:plugin.fallback}/error.pluginNotFound.xmap"/>
> </match>
>
> The we can dynamically install features at run time rather than at
> startup. We would even be able to add plugins at runtime.
>
> Still, I digress. I've added these comments to
> http://issues.apache.org/jira/browse/FOR-741 (good to see JIRA forcing
> me to add a component)
>
> >>In the meantime we need to advise users to add a version number as you
> >>discovered.
> >
> >I am surprised that we are not getting more pleas for
> >help from users of the 0.7 projectInfo plugin.
>
> It will only affect new users. Those who have the plugin installed
> already will not be trying to retrieve it, therefore no problem emerges..
However if anyone does a "build clean" then they
are going to hit this trouble, e.g. people with their
own Java customisations or someone doing 'build clean'
when they don't really need to. Stylesheet and sitemap
changes don't need to.
-David
Re: deployed plugins with wrong version number
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>David Crossley wrote:
>>
>>>Ross Gardler wrote:
>>>
>>>>David Crossley wrote:
>>>>
>>>>
>>>>>I wonder if it is because there in no "unversioned"
>>>>>plugin in the 0.7 directory. At 0.7 release time
>>>>>perhaps we needed to copy the unversioned ones there too.
>>>>
>>>>Yes, that will be it, I'll look into this ASAP. Thanks.
>>>
>>>I tried this by:
>>>cd forrest-site/plugins/0.7/
>>>svn cp org.apache.forrest.plugin.input.projectInfo-0.1.zip
>>>org.apache.forrest.plugin.input.projectInfo.zip
>>>svn commit
>>>... then waited for the hourly cronjob to 'svn update' our site.
>>>
>>>Then tried again with forrest_07 and same problem that was
>>>reported above.
>>>
>>>I noticed that it is trying to retrieve:
>>>http://forrest.apache.org/plugins//org.apache.forrest.plugin.input.projectInfo.zip
>>>... perhaps needs /0.7/ in that empty space.
>>
>>Thanks David. I'll have to dig into the build files to see what is
>>happening. Probaboly won't have the time until the end of the week at
>>the earliest.
>
>
> I did this today and it now works for me with forrest_07_branch.
>
> ---------------
> [main]$ svn diff var/pluginlist2fetch.xsl
> Index: var/pluginlist2fetch.xsl
> ===================================================================
> --- var/pluginlist2fetch.xsl (revision 329512)
> +++ var/pluginlist2fetch.xsl (working copy)
> @@ -46,7 +46,7 @@
> <target name="fetch-unversioned-plugin" unless="versioned-plugin.present">
> <echo>Versioned plugin unavailable, trying to get versionless plugin...</echo>
> <get verbose="true" usetimestamp="true" ignoreerrors="true">
> - <xsl:attribute name="src"><xsl:value-of select="plugin[@name=$plugin-name]/@url" />/<xsl:value-of select="$plugin-name" />.zip</xsl:attribute>
> + <xsl:attribute name="src"><xsl:value-of select="plugin[@name=$plugin-name]/@url" />/<xsl:value-of select="$forrest-version" />/<xsl:value-of select="$plugin-name" />.zip</xsl:attribute>
> ---------------
>
> So our plugin deployment process needs to put a copy
> of the plugin into the specific version directory, e.g.
> in plugins/0.8-dev/ and we need to manually add them to
> the plugins/0.7/ directory.
Thanks for looking at this David, as you guessed I have not had the time
yet. Something does not ring true for me with this patch. I don't have
the time to check the main plugin build.xml right now, but from memory:
What happens when a plugin is deployed is that a versioned copy is put
into the a specific Forrest directory (i.e. 0.8) and an unversioned copy
is put into the root distirbution directory (I *think* that I prevented
a versioned copy with a "-dev" version number going into the versioned
Forrest directory).
This means that a versioned copy is in the correct versioned forrest
directory (identified in the plugins own build.xml). Remember that a
plugin is intended to work with a minimum version of Forrest. The
unversioned copy of the plugin was plaved in the root unversioned
directory in order to minimise the number of copies that we need on the
server. The assumption was that people using development versions of
plugins will be using development versions of Forrest.
This is not a good assumption.
> Perhaps we then don't need the unversioned plugins at
> the plugins/ directory, rather only have them in the
> specific sub-directory.
Yes, and I think the version resolving gode needs to be refined as well.
Currently, if a plugin works in 0.7 and 0.8-dev I think we need a copy
of the plugin in both subdirectories as the plugin resolving code does
not check other directories. What we need is for the loading code to
look first in the correct Forrest version directory, then in the
previous version and so on until it finds the right version of the plugin.
We can hack this solutoin together in the ANT scripts fairly easily
(time allowing ;-)
For the future I want to create a new plugin resolving mechanism that
loads plugins at runtime rather than at startup. We need to modify the
Locationmap somthing like this:
<match pattern="plugin.xmap.*">
<location src="{project:tmp}/{1}/>
<install src="http://f.a.o/plugins/0.8/{1}/>
<install src="http://f.a.o/plugins/0.7/{1}/>
<location src="{forrest:plugin.fallback}/error.pluginNotFound.xmap"/>
</match>
The we can dynamically install features at run time rather than at
startup. We would even be able to add plugins at runtime.
Still, I digress. I've added these comments to
http://issues.apache.org/jira/browse/FOR-741 (good to see JIRA forcing
me to add a component)
>>In the meantime we need to advise users to add a version number as you
>>discovered.
>
>
> I am surprised that we are not getting more pleas for
> help from users of the 0.7 projectInfo plugin.
It will only affect new users. Those who have the plugin installed
already will not be trying to retrieve it, therefore no problem emerges..
Re: deployed plugins with wrong version number
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >>David Crossley wrote:
> >>
> >>>I wonder if it is because there in no "unversioned"
> >>>plugin in the 0.7 directory. At 0.7 release time
> >>>perhaps we needed to copy the unversioned ones there too.
> >>
> >>Yes, that will be it, I'll look into this ASAP. Thanks.
> >
> >I tried this by:
> >cd forrest-site/plugins/0.7/
> >svn cp org.apache.forrest.plugin.input.projectInfo-0.1.zip
> >org.apache.forrest.plugin.input.projectInfo.zip
> >svn commit
> >... then waited for the hourly cronjob to 'svn update' our site.
> >
> >Then tried again with forrest_07 and same problem that was
> >reported above.
> >
> >I noticed that it is trying to retrieve:
> >http://forrest.apache.org/plugins//org.apache.forrest.plugin.input.projectInfo.zip
> >... perhaps needs /0.7/ in that empty space.
>
> Thanks David. I'll have to dig into the build files to see what is
> happening. Probaboly won't have the time until the end of the week at
> the earliest.
I did this today and it now works for me with forrest_07_branch.
---------------
[main]$ svn diff var/pluginlist2fetch.xsl
Index: var/pluginlist2fetch.xsl
===================================================================
--- var/pluginlist2fetch.xsl (revision 329512)
+++ var/pluginlist2fetch.xsl (working copy)
@@ -46,7 +46,7 @@
<target name="fetch-unversioned-plugin" unless="versioned-plugin.present">
<echo>Versioned plugin unavailable, trying to get versionless plugin...</echo>
<get verbose="true" usetimestamp="true" ignoreerrors="true">
- <xsl:attribute name="src"><xsl:value-of select="plugin[@name=$plugin-name]/@url" />/<xsl:value-of select="$plugin-name" />.zip</xsl:attribute>
+ <xsl:attribute name="src"><xsl:value-of select="plugin[@name=$plugin-name]/@url" />/<xsl:value-of select="$forrest-version" />/<xsl:value-of select="$plugin-name" />.zip</xsl:attribute>
---------------
So our plugin deployment process needs to put a copy
of the plugin into the specific version directory, e.g.
in plugins/0.8-dev/ and we need to manually add them to
the plugins/0.7/ directory.
Perhaps we then don't need the unversioned plugins at
the plugins/ directory, rather only have them in the
specific sub-directory.
> In the meantime we need to advise users to add a version number as you
> discovered.
I am surprised that we are not getting more pleas for
help from users of the 0.7 projectInfo plugin.
-David
Re: deployed plugins with wrong version number
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>David Crossley wrote:
>>
>>>I wonder if it is because there in no "unversioned"
>>>plugin in the 0.7 directory. At 0.7 release time
>>>perhaps we needed to copy the unversioned ones there too.
>>
>>Yes, that will be it, I'll look into this ASAP. Thanks.
>
>
> I tried this by:
> cd forrest-site/plugins/0.7/
> svn cp org.apache.forrest.plugin.input.projectInfo-0.1.zip org.apache.forrest.plugin.input.projectInfo.zip
> svn commit
> ... then waited for the hourly cronjob to 'svn update' our site.
>
> Then tried again with forrest_07 and same problem that was
> reported above.
>
> I noticed that it is trying to retrieve:
> http://forrest.apache.org/plugins//org.apache.forrest.plugin.input.projectInfo.zip
> ... perhaps needs /0.7/ in that empty space.
Thanks David. I'll have to dig into the build files to see what is
happening. Probaboly won't have the time until the end of the week at
the earliest.
In the meantime we need to advise users to add a version number as you
discovered.
Ross
Re: deployed plugins with wrong version number
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >
> >I wonder if it is because there in no "unversioned"
> >plugin in the 0.7 directory. At 0.7 release time
> >perhaps we needed to copy the unversioned ones there too.
>
> Yes, that will be it, I'll look into this ASAP. Thanks.
I tried this by:
cd forrest-site/plugins/0.7/
svn cp org.apache.forrest.plugin.input.projectInfo-0.1.zip org.apache.forrest.plugin.input.projectInfo.zip
svn commit
... then waited for the hourly cronjob to 'svn update' our site.
Then tried again with forrest_07 and same problem that was
reported above.
I noticed that it is trying to retrieve:
http://forrest.apache.org/plugins//org.apache.forrest.plugin.input.projectInfo.zip
... perhaps needs /0.7/ in that empty space.
-David
Re: deployed plugins with wrong version number
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>David Crossley wrote:
>>
>>>David Crossley wrote:
>>>
>>>
>>>>David Crossley wrote:
>>>>
>>>>
>>>>>Ross, i needed to go back to 2 months ago. The projectInfo
>>>>>plugin started to use the locationmap at r278579
>>>>>and we must have accidently deployed it as version 0.7
>>>>>rather than as 0.8-dev
>>>>>
>>>>>Anyway, i redeployed that old input.projectInfo and
>>>>>redeployed the output.POD and output.Text plugins from
>>>>>yesterday.
>>>>>
>>>>>Then the site-author build worked fine using forrest-0.7
>>>>>
>>>>>Then re-deploying the version 0.8 of the projectInfo
>>>>>plugins caused the error again.
>>>>
>>>>The "fetch-versioned-plugin" ant target doesn't do anything
>>>>so it gets the unversioned 0.8 version and so fails.
>>>
>>>
>>>Oh, i was expecting it to magically figure out which
>>>version of the plugin it needed. Not so.
>>>
>>>We need to explicitly tell it in forrest.properties
>>>to use org.apache.forrest.plugin.input.projectInfo-0.1
>>>
>>>Does this mean that every 0.7 user of the projectInfo
>>>plugin will need to upgrade their forrest.properties ?
>>
>>
>>The intended behaviour is:
>
>
> THanks for the great explanation. I will snip that
> into a document later.
I thought I had documented it , but it may not have been that clear.
...
> I wonder if it is because there in no "unversioned"
> plugin in the 0.7 directory. At 0.7 release time
> perhaps we needed to copy the unversioned ones there too.
Yes, that will be it, I'll look into this ASAP. Thanks.
Ross
Re: deployed plugins with wrong version number
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >David Crossley wrote:
> >
> >>David Crossley wrote:
> >>
> >>>Ross, i needed to go back to 2 months ago. The projectInfo
> >>>plugin started to use the locationmap at r278579
> >>>and we must have accidently deployed it as version 0.7
> >>>rather than as 0.8-dev
> >>>
> >>>Anyway, i redeployed that old input.projectInfo and
> >>>redeployed the output.POD and output.Text plugins from
> >>>yesterday.
> >>>
> >>>Then the site-author build worked fine using forrest-0.7
> >>>
> >>>Then re-deploying the version 0.8 of the projectInfo
> >>>plugins caused the error again.
> >>
> >>The "fetch-versioned-plugin" ant target doesn't do anything
> >>so it gets the unversioned 0.8 version and so fails.
> >
> >
> >Oh, i was expecting it to magically figure out which
> >version of the plugin it needed. Not so.
> >
> >We need to explicitly tell it in forrest.properties
> >to use org.apache.forrest.plugin.input.projectInfo-0.1
> >
> >Does this mean that every 0.7 user of the projectInfo
> >plugin will need to upgrade their forrest.properties ?
>
>
> The intended behaviour is:
THanks for the great explanation. I will snip that
into a document later.
> If a version is specified download that version from the correct plugins
> distribution directory.
>
> If no version is specified download the unversioned plugin from the
> correct plugins distribution directory.
>
> ---
>
> There are a few things that could be going wrong. I have no time to
> check right now:
>
> a) plugins are deployed correctly, but downloaded incorrectly
>
> b) plugins are deployed incorrectly, but downloaded correctly
>
> c) plugins are deployed incorrectly, and downloaded incorrectly
>
> We need to find out which is which. If I remember correctly (and this is
> from memory, so may be incorrect in the finer details) it works like this:
>
> deploy
> ------
>
> If there is a "-dev" in the plugin version number in the plugins
> build.xml file, deploy an unversioned copy in the distribtion directory
> identified by the Forrest build number in the plugins build.xml
>
> If there is no "-dev" in the plugin version number in the plugins
> build.xml file, deploy a versioned copy in the distribtion directory
> identified by the Forrest build number in the plugins build.xml
>
> install
> -------
>
> If no version number specified in forrest.properties download the
> unversioned plugin for the version of forrest specified in Forrests
> build.xml.
>
> If a version number is specified in forrest.properties download the
> versioned plugin for the version of forrest specified in Forrests
> build.xml. If the specified version cannot be found, fall back to the
> unversioned one.
>
> NOTE
> ====
>
> The version number in the plugins.xml is only for documentation. It
> should really be generated from the info in build.xml, but I've not got
> round to doing that yet: http://issues.apache.org/jira/browse/FOR-533
I wonder if it is because there in no "unversioned"
plugin in the 0.7 directory. At 0.7 release time
perhaps we needed to copy the unversioned ones there too.
-David
Re: deployed plugins with wrong version number
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> David Crossley wrote:
>
>>David Crossley wrote:
>>
>>>Ross, i needed to go back to 2 months ago. The projectInfo
>>>plugin started to use the locationmap at r278579
>>>and we must have accidently deployed it as version 0.7
>>>rather than as 0.8-dev
>>>
>>>Anyway, i redeployed that old input.projectInfo and
>>>redeployed the output.POD and output.Text plugins from
>>>yesterday.
>>>
>>>Then the site-author build worked fine using forrest-0.7
>>>
>>>Then re-deploying the version 0.8 of the projectInfo
>>>plugins caused the error again.
>>
>>The "fetch-versioned-plugin" ant target doesn't do anything
>>so it gets the unversioned 0.8 version and so fails.
>
>
> Oh, i was expecting it to magically figure out which
> version of the plugin it needed. Not so.
>
> We need to explicitly tell it in forrest.properties
> to use org.apache.forrest.plugin.input.projectInfo-0.1
>
> Does this mean that every 0.7 user of the projectInfo
> plugin will need to upgrade their forrest.properties ?
The intended behaviour is:
If a version is specified download that version from the correct plugins
distribution directory.
If no version is specified download the unversioned plugin from the
correct plugins distribution directory.
---
There are a few things that could be going wrong. I have no time to
check right now:
a) plugins are deployed correctly, but downloaded incorrectly
b) plugins are deployed incorrectly, but downloaded correctly
c) plugins are deployed incorrectly, and downloaded incorrectly
We need to find out which is which. If I remember correctly (and this is
from memory, so may be incorrect in the finer details) it works like this:
deploy
------
If there is a "-dev" in the plugin version number in the plugins
build.xml file, deploy an unversioned copy in the distribtion directory
identified by the Forrest build number in the plugins build.xml
If there is no "-dev" in the plugin version number in the plugins
build.xml file, deploy a versioned copy in the distribtion directory
identified by the Forrest build number in the plugins build.xml
install
-------
If no version number specified in forrest.properties download the
unversioned plugin for the version of forrest specified in Forrests
build.xml.
If a version number is specified in forrest.properties download the
versioned plugin for the version of forrest specified in Forrests
build.xml. If the specified version cannot be found, fall back to the
unversioned one.
NOTE
====
The version number in the plugins.xml is only for documentation. It
should really be generated from the info in build.xml, but I've not got
round to doing that yet: http://issues.apache.org/jira/browse/FOR-533
Ross
Ross
Re: deployed plugins with wrong version number
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> David Crossley wrote:
> >
> > Ross, i needed to go back to 2 months ago. The projectInfo
> > plugin started to use the locationmap at r278579
> > and we must have accidently deployed it as version 0.7
> > rather than as 0.8-dev
> >
> > Anyway, i redeployed that old input.projectInfo and
> > redeployed the output.POD and output.Text plugins from
> > yesterday.
> >
> > Then the site-author build worked fine using forrest-0.7
> >
> > Then re-deploying the version 0.8 of the projectInfo
> > plugins caused the error again.
>
> The "fetch-versioned-plugin" ant target doesn't do anything
> so it gets the unversioned 0.8 version and so fails.
Oh, i was expecting it to magically figure out which
version of the plugin it needed. Not so.
We need to explicitly tell it in forrest.properties
to use org.apache.forrest.plugin.input.projectInfo-0.1
Does this mean that every 0.7 user of the projectInfo
plugin will need to upgrade their forrest.properties ?
-David
Re: deployed plugins with wrong version number
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
>
> Ross, i needed to go back to 2 months ago. The projectInfo
> plugin started to use the locationmap at r278579
> and we must have accidently deployed it as version 0.7
> rather than as 0.8-dev
>
> Anyway, i redeployed that old input.projectInfo and
> redeployed the output.POD and output.Text plugins from
> yesterday.
>
> Then the site-author build worked fine using forrest-0.7
>
> Then re-deploying the version 0.8 of the projectInfo
> plugins caused the error again.
The "fetch-versioned-plugin" ant target doesn't do anything
so it gets the unversioned 0.8 version and so fails.
-David