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
