[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aperi-dev] V0.3 GUI install
|
1. Yes. As Sumant pointed out, people
may want to use the GUI independently of the server. For example, a storage
administrator might install the GUI on his laptop so that he can manage
his environment while he's on the road.
2. Yes. It should be possible to install
the GUI at the same time as everything else (i.e., Data Server, Device
Server, etc.). However, it should not be required. I don't remember...
Is that what we do today with ConfigureAperi?
3. Yes. I think we start moving away
from the legacy GUI as soon as possible, in favor of the RCP GUI. Given
that the legacy GUI is embedded in the RCP GUI, I don't think we lose anything.
And, the more reps our RCP stuff gets, the better.
Regards,
Khan Tasinga
IBM Tivoli Software Engineer / Aperi Development
Phone: (408) 284-5142 | T/L: 8-953-5142
Email: kmtasing@xxxxxxxxxx
Dave Wolfe/Portland/IBM@IBMUS
Sent by: aperi-dev-bounces@xxxxxxxxxxx
01/31/2007 12:17 PM
Please respond to
Aperi Development <aperi-dev@xxxxxxxxxxx> |
|
To
| aperi-dev@xxxxxxxxxxx
|
cc
|
|
Subject
| [aperi-dev] V0.3 GUI install |
|
I realize I have been kind of fuzzily assuming that the V0.3 GUI would
have an independent install. That is, it wouldn't be installed as part
of the current zip file or configured with cfgaperi. My visions is you
would install the server in one step then install the GUI (where ever you
liked) in a separate step. I doubt that's what others expect.
My reasoning being that it is indeed an independent RCP application that
gets bundled into its own little zip file by the PDE build tools and then
gets installed like any other Eclipse RCP like app.
That is, you download a zip or tar file and just expand it into a directory,
then launch the executable.
Assuming we get organized, the components could be installed via Java Web
Start and maintained via the Eclipse Update Center capability (we get this
more or less for free as an RCP app).
At this time it is an independent build (not part of the regular Aperi
build) although I expect for convenience we will run the server and new
GUI nightly builds at the same time(stamp).
In order to make the new GUI part of the server bundle we could run it
as sub-build and package it into the base bundle then cfgaperi could unzip
it for us.
One more little spin: the legacy (Swing based) GUI is still built and installable
as before. If we include the new GUI is the standard bundle we should eliminate
the legacy GUI.
So, the questions are:
1) Should the new GUI have an independent install capability (y/n)?
2) Should the new GUI be bundled with the server and installed along with
everything else (y/n)?
3) Should we eliminate the legacy GUI from the server install bundle (y/n)?
Dave Wolfe/Portland/IBM
(dwolfe@xxxxxxxxxx)
TL: 775-3376 Office: 503-578-3376 Personal: 503-329-3960
GUI Technical Lead, Aperi Open Source Storage Management
http://www.eclipse.org/aperi
http://www.ibm.com
If all of your problems look like nails you should invest
in a good hammer - Unknown_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev