Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: softfail (herse.apache.org: transitioning domain of
 webmaster@cfas.org does not designate 65.32.5.134 as permitted sender)
Message-ID: <461CDA5C.4000209@cfas.org>
Date: Wed, 11 Apr 2007 08:53:48 -0400
From: CFAS Webmaster <webmaster@cfas.org>
User-Agent: Thunderbird 1.5.0.10 (X11/20070304)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: plugins deployment problem (Was: 0.8RC1 Failure)
References: <461BFCE4.2090607@apache.org>
 <20070411010534.GT8244@igg.indexgeo.com.au>
 <20070411021924.GU8244@igg.indexgeo.com.au>
 <20070411023814.GV8244@igg.indexgeo.com.au>
 <20070411034805.GW8244@igg.indexgeo.com.au>
 <20070411074725.GY8244@igg.indexgeo.com.au> <461CA2BD.104@apache.org>
 <20070411120922.GZ8244@igg.indexgeo.com.au>
In-Reply-To: <20070411120922.GZ8244@igg.indexgeo.com.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
>