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, 17 Feb 2006 11:25:03 GMT
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
> 
> 
> 


Mime
View raw message