forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: deployed plugins with wrong version number
Date Fri, 25 Nov 2005 10:50:31 GMT
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..

Mime
View raw message