On 7/26/06, Ross Gardler <[EMAIL PROTECTED]> wrote:
Tim Williams wrote:
> On 7/26/06, Ross Gardler <[EMAIL PROTECTED]> wrote:
>
>> Tim Williams wrote:
>> > On 7/26/06, Ross Gardler <[EMAIL PROTECTED]> wrote:
>> >
>> >> Tim Williams (JIRA) wrote:
>> >> > Discussed here to:
>> >> > http://marc.theaimsgroup.com/?t=115257903800001&r=1&w=4
>> >> >
>> >> > I still agree with what I proposed in that mail. I actually like
>> >> Ross' suggestion too but only if we move towards better
>> >> packaging/managing/releasing of plugins.
>> >>
>> >> What do you think is needed?
...
>> > o) Improved versioning - externally identifiable.
>>
>> What do you mean "externally identifiable", is it not sufficient i the
>> current form i.e. "pluginName-0.1", "pluginName-0.2"
>
>
> Shucks, I could be showing my ignorance on this plugin versioning
> stuff, but when I go to:
> http://forrest.apache.org/plugins/
> I see only plugin names, not versions. I would expect to see
> org.apache.forrest.plugin.input.excel.v01.zip
> org.apache.forrest.plugin.input.excel.v02.zip
> org.apache.forrest.plugin.input.excel.v03.zip
> or some such.
Take a look at http://forrest.apache.org/plugins/0.7/
see the version numbers?
It works like this:
no version number means the version is not an official release it is an
"in development" release. This is what is used if no version number is
placed in the forest.properties file.
with a version number it means it is an official release (not that we
have a process for official releases yet). Such releases are stable and
will never change. This is what is used if a version number is expressed
in forrest.properties
This is "documented" at [1] (docs certainly need improvement)
Doing "ant deploy" on a plugin will deploy the *in development* version
this can be done much more frequently than a release as it does not
require the same attention to detail as a full release.
Doing "ant release" on a plugin will deploy a *release* version,
complete with version number.
David and I discussed this a great deal in an early Forrest Friday. We
started some documentation for the release process [2]
Does this satisfy your needs?
>> > I'm talking about manually not automagically.
>>
>> Why manually?
>>
>> Even if there is a good use case it can already be done manually using
>> the existing ant targets. It's not documented that way as I've never
>> considered a user needing to do this.
>
>
> There are very large intranets in the world today that are not
> connected to the internet. I don't think we can assume an internet
> connection. What's needed is the ability to burn plugins to CD and
> use the "sneaker-net" to move it to the running forrest application.
That has always been supported. Just create a plugin repository on the
Intranet and point Forrest at it.
>> > o) Combined with the above, improved manually downloading of plugins.
>>
>> OK the plugins index page needs download links to the actual files
>> rather than the download directory and it should have instructions on
>> where to save the files.
>
>
> Right and, I think, a list of links of the different versions
> including "Latest" an "Previous".
...
>> What else needs to be improved?
>
>
> Probably a better plugin page in general. It's currently an
> overwhelming laundry list of plugins. Maybe we should consider only
> listing the plugin names with one-line descriptions then deferring the
> rest of the content to the plugin docs?
The page is currently generated by the sitemap.xmap:
<map:match pattern="pluginDocs/plugins_(.*)/index(|\.source).xml"
type="regexp">
<map:aggregate element="pluginList">
<map:part src="{lm:plugin.descriptor.forrest}"/>
<map:part src="{lm:plugin.descriptor.whiteboard}"/>
</map:aggregate>
<map:transform src="{lm:transform.plugins.xdoc}"/>
<map:serialize type="xml"/>
</map:match>
(not saying you should do it, I'm putting a useful reference here for
anyone who has the urge - I'll link this thread to the issue in a few
minutes)
>> However, why would anyone need to download them manually? Cyriaque has
>> solved the proxy problems as far as I can tell, what else would force
>> manual download?
>
>
> As I say above, there are some folks that are physically disconnected
> from the internet and the "automagic" stuff doesn't work.
I beg to differ. See my comment above.
If there is one central Forrest installation for the whole Intranet then
just drop the required plugin zips into the install directory.
If there are multiple installations of Forrest on the Intranet then
create a local repository and use that. Synchronise it occasionally with
the live one and bingo all your installations will automagically update
themselves.
How people get the zips is not our concern, somewhere along the line
someone must have access to the Internet in order to get Forrest in the
first plave. They can therefore get the zips using wget or a mnaul
download process.
Of course, if you have an idea about an even easier process...
Ross
[1]
http://forrest.apache.org/pluginDocs/plugins_0_80/usingPlugins.html#version
[2]
http://svn.apache.org/viewvc/forrest/trunk/plugins/RELEASE_PROCESS.txt?view=markup
I'm satisfied with this for this release. I think the download links
and plugin docs need enhancements prior to a future release though to
remove some of the sublety of this stuff. I've [wrongly] been viewing
each plugin's documentation as more a demo-area for the plugin rather
than a self-contained "micro-project" site. I think download links,
versions, authors, etc. should be moved there instead of the main
plugin index page.
--tim
