You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by "Ross Gardler (JIRA)" <ji...@apache.org> on 2007/04/04 23:15:32 UTC

[jira] Commented: (FOR-742) trouble accessing unversioned plugin for a released version of Forrest, e.g. projectInfo

    [ https://issues.apache.org/jira/browse/FOR-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486778 ] 

Ross Gardler commented on FOR-742:
----------------------------------

I've deployed the plugins by manually copying the relevant versioned plugins to as the unversioned plugin. 

We still need to test this.

When testing we need to temporarily rename the forrest src directory to ensure that the plugins will be downloaded rather than used from the src directory.

> trouble accessing unversioned plugin for a released version of Forrest, e.g. projectInfo
> ----------------------------------------------------------------------------------------
>
>                 Key: FOR-742
>                 URL: https://issues.apache.org/jira/browse/FOR-742
>             Project: Forrest
>          Issue Type: Bug
>          Components: Plugins (general issues)
>    Affects Versions: 0.7, 0.8-dev
>            Reporter: David Crossley
>            Priority: Critical
>             Fix For: 0.8-dev
>
>
> The plugin retrieval and deployment process are not quite correct. Recently the projectInfo plugin had its version number incremented and the "unversioned" plugin now relates specifically to 0.8-dev version. That prevents 0.7 from accessing the relevant plugin.
> The solution is discussed here:
> http://marc.theaimsgroup.com/?t=113176328300002

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Re: Plugin resolutoin (was Re: [jira] Commented: (FOR-742) trouble accessing unversioned plugin for a released version of Forrest, e.g. projectInfo)

Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>> David Crossley wrote:
>>> Ross Gardler wrote:
>>>> Ross Gardler (JIRA) wrote:
>>>>> Ross Gardler commented on FOR-742:
>>>>> ----------------------------------
>>>>>
>>>>> I've deployed the plugins by manually copying the relevant versioned 
>>>>> plugins to as the unversioned plugin. 
>>>> I added these by ssh to people.apache.org then doing copying the files 
>>>> in /www/forrest.apache.org/plugins/* followed by relevant svn add.
>>>>
..

>>> However there are other issues ...
>>>
>>> -----------
>>> The plugins have been deployed haphazardly over the time
>>> since the 0.7 release. I was hoping that someone would
>>> review and deploy each. Then we would follow up with copying
>>> them to the unversioned space.
>> This cannot be done without alot of work, and I don't think it is 
>> necessary. We would have to find the point in SVN that the plugin became 
>> a 0.8 plugin, roll back to that time and deploy.
> 
> That is not what i meant, sorry.
> 
> Some of the plugins have been deployed many times
> and so are reasonably up-to-date. Other plugins
> have been worked on in trunk since being deployed.
> The latter changes are not reflected in the currently
> deployed plugin.
> 
> It just takes someone to quickly look at each plugin's
> site, be happy, then deploy both the plugin and its website.

Ah, deploy. OK. Leave it to me.

>>> -----------
>>> I see that you don't have your 'umask' set, so now the files
>>> that you copied have the wrong group permissions and so the
>>> other committers cannot update.
>>> http://www.qpache.org/dev/new-committers-guide.html#shell
>> Really? I've set that in the past. Still I'ce done it again, thanks for 
>> the heads up. I've also sorted out the SVN status.
> 
> However there is still the group permissions problem.
> Please do:
> ssh people.apache.org
> cd /www/forrest.apache.org/plugins
> chgrp -R forrest *

Really? Then my umask setting still doesn't work. Strange.

I've done the chgrp and checked my umask setting again. Perhaps I forgot 
to logout and back in again when I set it last and "fixed" the SVN stuff.

Thanks (once again) for following in my tracks.

Ross


Re: Plugin resolutoin (was Re: [jira] Commented: (FOR-742) trouble accessing unversioned plugin for a released version of Forrest, e.g. projectInfo)

Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >>Ross Gardler (JIRA) wrote:
> >>>Ross Gardler commented on FOR-742:
> >>>----------------------------------
> >>>
> >>>I've deployed the plugins by manually copying the relevant versioned 
> >>>plugins to as the unversioned plugin. 
> >>I added these by ssh to people.apache.org then doing copying the files 
> >>in /www/forrest.apache.org/plugins/* followed by relevant svn add.
> >>
> >>Am I correct in thinking these changes will make it to the live server 
> >>on the next automated update?
> >
> >Yes they would be picked up on the next rsync.
> >http://www.apache.org/dev/project-site.html
> >
> >I have a local SVN working copy of forrest/site/ so i do
> >such things locally. I didn't think to do it via ssh.
> >That should work.
> >
> >You should have done an 'svn copy' rather than manual copy
> >and then 'svn add'. Also i notice that you haven't done 'svn commit'.
> 
> Yes, I should have done copy, not sure why I didn't. As for the commit, 
> I tried to, but it wouldn't let me. I assumed that I didn't have the 
> permissions because it was going to commit to the public server.

I just did a test. Me too.

> I also should have done it in 
> http://svn.apache.org/repos/asf/forrest/site/plugins (as you suggest) as 
> this is a read only repo.
>
> I was going from memory. Unfortunately it is faulty, I thought that in 
> the past I have done things things here to speed things up. In fact, 
> what needs to be done is you do it in the above then do an SVN up from 
> people.apache.org. this forces an immediate website update. Serves me 
> right for doing it from memory.

I have a cronjob that does the 'svn up' every hour at 07 past.
Then the ASF wide rysnc kicks in at 11 past.
I need to document that somewhere:
http://forrest.apache.org/procedures/How_to_publish_docs.html

> I've cleared up this mess now.
>
> >However there are other issues ...
> >
> >-----------
> >The plugins have been deployed haphazardly over the time
> >since the 0.7 release. I was hoping that someone would
> >review and deploy each. Then we would follow up with copying
> >them to the unversioned space.
> 
> This cannot be done without alot of work, and I don't think it is 
> necessary. We would have to find the point in SVN that the plugin became 
> a 0.8 plugin, roll back to that time and deploy.

That is not what i meant, sorry.

Some of the plugins have been deployed many times
and so are reasonably up-to-date. Other plugins
have been worked on in trunk since being deployed.
The latter changes are not reflected in the currently
deployed plugin.

It just takes someone to quickly look at each plugin's
site, be happy, then deploy both the plugin and its website.

 [ snip ]

Thanks for the excellent explanation. Let us hope that
we can make it all easier. If not then we need to refer
to this email thread as some documentation for next time.

> >-----------
> >I see that you don't have your 'umask' set, so now the files
> >that you copied have the wrong group permissions and so the
> >other committers cannot update.
> >http://www.qpache.org/dev/new-committers-guide.html#shell
> 
> Really? I've set that in the past. Still I'ce done it again, thanks for 
> the heads up. I've also sorted out the SVN status.

However there is still the group permissions problem.
Please do:
ssh people.apache.org
cd /www/forrest.apache.org/plugins
chgrp -R forrest *

-David

Plugin resolutoin (was Re: [jira] Commented: (FOR-742) trouble accessing unversioned plugin for a released version of Forrest, e.g. projectInfo)

Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>> Ross Gardler (JIRA) wrote:
>>>    [ 
>>>    https://issues.apache.org/jira/browse/FOR-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486778 ] 
>>>
>>> Ross Gardler commented on FOR-742:
>>> ----------------------------------
>>>
>>> I've deployed the plugins by manually copying the relevant versioned 
>>> plugins to as the unversioned plugin. 
>> I added these by ssh to people.apache.org then doing copying the files 
>> in /www/forrest.apache.org/plugins/* followed by relevant svn add.
>>
>> Am I correct in thinking these changes will make it to the live server 
>> on the next automated update?
> 
> Yes they would be picked up on the next rsync.
> http://www.apache.org/dev/project-site.html
> 
> I have a local SVN working copy of forrest/site/ so i do
> such things locally. I didn't think to do it via ssh.
> That should work.
> 
> You should have done an 'svn copy' rather than manual copy
> and then 'svn add'. Also i notice that you haven't done 'svn commit'.

Yes, I should have done copy, not sure why I didn't. As for the commit, 
I tried to, but it wouldn't let me. I assumed that I didn't have the 
permissions because it was going to commit to the public server.

I also should have done it in 
http://svn.apache.org/repos/asf/forrest/site/plugins (as you suggest) as 
this is a read only repo.

I was going from memory. Unfortunately it is faulty, I thought that in 
the past I have done things things here to speed things up. In fact, 
what needs to be done is you do it in the above then do an SVN up from 
people.apache.org. this forces an immediate website update. Serves me 
right for doing it from memory.

I've cleared up this mess now.

> However there are other issues ...
> 
> -----------
> The plugins have been deployed haphazardly over the time
> since the 0.7 release. I was hoping that someone would
> review and deploy each. Then we would follow up with copying
> them to the unversioned space.

This cannot be done without alot of work, and I don't think it is 
necessary. We would have to find the point in SVN that the plugin became 
a 0.8 plugin, roll back to that time and deploy.

Recall that we introduced a two phase aproach recently, deploy and 
release. I don't think we have actually released any plugins recently 
(certainly we have not voted for one).

The deployment/release problem was fixed immediately after we realised 
the problem with the projectInfo plugin, which was the first to be 
upgraded to Forrest 0.8. Since then all deployments have been to the 
correct directoy. Therefore, whatever is in the plugins/0.7 directory is 
a working plugin for 0.7.

> -----------
> I wonder if you done things the wrong way around.
> When we deploy a plugin, it goes into the forrest/site SVN
> at plugins/0.8/ directory.

Not wuite right.

When we deploy, as opposed to release, a plugin it is put into the
plugins root directory (no forrest version number). This plugin version 
has no version number.

When we release it goes into plugins/[FORREST_VERSION]. This version has 
a version number.

So by specifying a plugin version number in forrest.properties we say we 
want a specific plugin version that works on my current Forrest version.

By not specifying a plugin version number we are saying we want the most 
recent plugin that is known to work with my current Forrest version.

I'll explore the significance of this below.

> Also i see a lot of additions in the 0.7 directory. Why?

When we try and retrieve a plugin the order is:

- local plugin
- remote plugin, versioned Forrest
- remote plugin, unversioned forrest

Whether we are looking for a versioned or unversioned plugin depends on 
the settings in forrest.properties.

So, lets imagine our Forrest content object specifies an unversioned 
copy of the projectInfo plugin and that the local source files are not 
available. The process is:

- look for local src files [NOT FOUND]
- look for a remote unversioned copy in forrest.apache.org/plugins/0.7/

Previously this second step would fail since there was no unversioned 
copy in that directory. And so it would progress to the third step:

- look for a remote unversioned copy in forrest.apache.org/plugins

This would succeed, but the plugin would be for forrest version 0.8, and 
would therefore break in 0.7

What I have done is made an unversioned copy of the latest release in 
plugins/o.7 so the second step would succeed.

Why do it this way?

So that we can have development (i.e. none released) versions of plugins 
available for multiple versions of Forrest. This means someone using 
Forrest 0.7 can still work on the plugin without it interfering with the 
latest head development of the plugin. In addition, plugins can have 
independent release cycles for different versions of Forrest. This 
allows a bug to be fixed in a Forrest 0.7 version of a plugin 
independantly of changes in the Forrest 0.8 version.

---

So, in sumamry.

forrest.apache.org/plugins/0.x should contain *released* versioned and 
unversioned plugins for Forrest 0.x

forrest.apache.org/plugins should contain *deployed* (but not released) 
plugins for Forrest 0.8

This is not the tidiest way of doing things, but currently the download 
mechanism is written as an ANT script and therefore we are limited to 
what is possible (and still readable) in an Ant script. There is an 
issue to rewrite this in Java, but it has not received attention yet and 
may well be superceeded by the 0.9 move Ivy.


> -----------
> Should this action of "copying to the unversioned space"
> have happened at a later stage of the release process?
> I wonder if they are now busted for users of the current
> 0.7 release.

No, it will not affect current users. See explanation above.

In fact this duplication of downloads should be done at plugin release time.

BUT...

It does need testing to make sure my assumptions and reading of the 
build files are correct.

> -----------
> I see that you don't have your 'umask' set, so now the files
> that you copied have the wrong group permissions and so the
> other committers cannot update.
> http://www.apache.org/dev/new-committers-guide.html#shell

Really? I've set that in the past. Still I'ce done it again, thanks for 
the heads up. I've also sorted out the SVN status.

Ross

Re: [jira] Commented: (FOR-742) trouble accessing unversioned plugin for a released version of Forrest, e.g. projectInfo

Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Ross Gardler (JIRA) wrote:
> >    [ 
> >    https://issues.apache.org/jira/browse/FOR-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486778 ] 
> >
> >Ross Gardler commented on FOR-742:
> >----------------------------------
> >
> >I've deployed the plugins by manually copying the relevant versioned 
> >plugins to as the unversioned plugin. 
> 
> I added these by ssh to people.apache.org then doing copying the files 
> in /www/forrest.apache.org/plugins/* followed by relevant svn add.
> 
> Am I correct in thinking these changes will make it to the live server 
> on the next automated update?

Yes they would be picked up on the next rsync.
http://www.apache.org/dev/project-site.html

I have a local SVN working copy of forrest/site/ so i do
such things locally. I didn't think to do it via ssh.
That should work.

You should have done an 'svn copy' rather than manual copy
and then 'svn add'. Also i notice that you haven't done 'svn commit'.

However there are other issues ...

-----------
The plugins have been deployed haphazardly over the time
since the 0.7 release. I was hoping that someone would
review and deploy each. Then we would follow up with copying
them to the unversioned space.

That way we are sure that everying is synchronised at
the time of 0.8 release.

-----------
I wonder if you done things the wrong way around.
When we deploy a plugin, it goes into the forrest/site SVN
at plugins/0.8/ directory. So i would have thought that they
would get copied up to the higher level directory.

Also i see a lot of additions in the 0.7 directory. Why?

-----------
Should this action of "copying to the unversioned space"
have happened at a later stage of the release process?
I wonder if they are now busted for users of the current
0.7 release.

-----------
I see that you don't have your 'umask' set, so now the files
that you copied have the wrong group permissions and so the
other committers cannot update.
http://www.apache.org/dev/new-committers-guide.html#shell

-David

Re: [jira] Commented: (FOR-742) trouble accessing unversioned plugin for a released version of Forrest, e.g. projectInfo

Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler (JIRA) wrote:
>     [ https://issues.apache.org/jira/browse/FOR-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486778 ] 
> 
> Ross Gardler commented on FOR-742:
> ----------------------------------
> 
> I've deployed the plugins by manually copying the relevant versioned plugins to as the unversioned plugin. 

I added these by ssh to people.apache.org then doing copying the files 
in /www/forrest.apache.org/plugins/* followed by relevant svn add.

Am I correct in thinking these changes will make it to the live server 
on the next automated update?

Ross