geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Daughtrey <er...@schemacity.org>
Subject Re: v1.x Installer comments - Long
Date Sun, 29 Jan 2006 22:15:34 GMT

David,

Thank you.

The installer now has two modes.  The default mode removes the advanced 
features which allow overriding of the config.xml load variables and defaults 
the values to true for the packs selected.  In this mode, the operator must 
select either Jetty or Tomcat for install and cannot install both.

If -Dadvancedmode=true is specified on the command line, then it is possible 
to install both web containers, but only one may be active at runtime.  
Additionally, the various components can be set to load=false as desired.  
The program enforces the dependencies. It's not possible to enable CORBA if 
J2EE features are not enabled.  We can choose not to document this.

Sorry if this situation has folks rattled.  I'm not rattled about this, nor at 
anyone. Apologies if anyone thinks so.

I'll be posting a patch after I do some more testing. Thanks.

note:  the property is not case sensitive.

Regards,

erik

 On Friday 27 January 2006 12:49, David Jencks wrote:
> I'm afraid that there is a temptation we might be succumbing to to
> gold plate the installer since only eric is actually doing the
> work.    We can easily turn the installer into a permanent full time
> job for as many people as we can get to work on it.
>
> Working on the installer is no fun IMNSHO based on my experience.  I
> want this part of the project to end really soon so eric can do
> something a bit more fun.
>
> My point of view about the function of the installer is that it is
> the primary means we can show the component oriented nature of
> geronimo and let people build their own server.  It is considerably
> harder to set up geronimo using the installer than to unpack one of
> the prebuilt servers, and nothing we can do can change that.
>
> I want the installer to show that you can build a lot of different
> servers out of the configurations we supply.  This means to me that
> it should  include exactly the parts you specify and that the
> configuration options for those parts you specify should be able to
> be set in the installer.  One of those configuration options is very
> definitely whether the configuration is started, so IMO it should be
> shown in the installer.
>
> My preference would be to fix the icons, make the changes so only the
> jars for the configs you select are installed, and declare victory.
>
> If we want more, I would prefer to insert warnings rather than
> disable functionality.  For instance, put a divider in between the
> ports etc and the check boxes for activating the configs that says
> "ADVANCED FUNCTIONALITY KEEP OUT" (obviously bad wording) and perhaps
> a warning page if you select 2 web containers "YOU PROBABLY DON"T
> WANT TO DO THAT".
>
> That's more than enough of a rant.  To me the only critical missing
> piece in the installer is including only the needed jars.
>
> thanks
> david jencks
>
> On Jan 27, 2006, at 8:22 AM, Dave Colasurdo wrote:
> > David Jencks wrote:
> >> On Jan 27, 2006, at 5:54 AM, Erik Daughtrey wrote:
> >>> Given the comments I've gotten, I'm going to change the installer
> >>> and go back
> >>> to the behavior where it does not allow the selection of both web
> >>> container
> >>> packs to install. I'm going to ditch the additional buttons which
> >>> allow
> >>> selected features to be inactive at runtime.
> >>>
> >>> We could put this up for a vote, but since there have been very
> >>> few comments
> >>> on this topic, I assume that most folks just want an installer
> >>> that works
> >>> well.
> >>
> >> I pretty much strongly prefer the way the installer works now, I
> >> think I asked for it to be this way :-)
> >> I won't stand in anyones way though.
> >> My view is that the installer should present all the options
> >> reasonably available.  They are MUCH easier to configure in the
> >> installer than in any other way, and I think that the additional
> >> confusion while using the installer is minimal.
> >
> > I think most folks agree that the vast majority of users will never
> > want
> > to run with two web containers installed.  The exceptions that I can
> > think of are:
> >
> > 1) Geronimo developers - who most likely won't ever use the installer
> >
> > 2) Novice users who aren't sure which web container to use and want to
> > try them both out. Rather than confusing them with instructions on how
> > to setup ports for simultaneous containers or instructions on how to
> > switch between web containers (creating two separate config stores or
> > enabling the config to use just certain portions of the same
> > config-store). Isn't it just simpler/easier to have them lay down two
> > separate *isolated* installations for their comparisons?
> >
> > IMHO, the confusion of someone accidentally laying down two web
> > containers outweighs any potential benefit.
> >
> > Concerning the enable/disable of selected components.  It seems quite
> > strange to select installation options on panel 1 and then have
> > panel 4
> > and panel 5 ask if you want the options that you selected on panel 1
> > enabled.  I would guess that an average user might think "Didn't I
> > already tell the installer I want these options installed?"
> >
> > What is the common use case for someone wanting to install an
> > option and
> > then disable it immediately in the installer?
> >
> > Thanks
> > -Dave-
> >
> >> thanks
> >> david jencks
> >>
> >>> regards,
> >>>
> >>> erik
> >>>
> >>>  On Wednesday 25 January 2006 21:53, Matt Hogstrom wrote:
> >>>> David Jencks wrote:
> >>>>> On Jan 25, 2006, at 2:48 PM, Joe Bohn wrote:
> >>>>>> I agree with Dave on the issue of multiple containers.  We had
> >>>>>> many
> >>>>>> discussions on this list concerning the number of containers
> >>>>>> in an
> >>>>>> image.  The result was that we agreed to deliver 2 different
> >>>>>> assemblies rather than having multiple containers in one
> >>>>>> assembly.
> >>>>>> If that was the decision for the assemblies then I would think
it
> >>>>>> makes sense to do the same in the installer.
> >>>>
> >>>> +1 One container per instance will satisfy 99% of the users I
> >>>> suspect.
> >>>>
> >>>>>> I also agree with Dave that we should revisit the issue of
> >>>>>> presenting
> >>>>>> the list of components twice: once to include them in  the
> >>>>>> image and
> >>>>>> once to activate them in the runtime.  I doubt that  most
> >>>>>> users would
> >>>>>> understand this distinction when initially  installing
> >>>>>> Geronimo.  Most
> >>>>>> other packages consider the activation/ inactivation of
> >>>>>> components to
> >>>>>> be post-install setup and choose the  defaults that make the
most
> >>>>>> sense.  In our case I would expect that  all components selected
> >>>>>> during install would be active by default.
> >>>>>
> >>>>> I think that is what we have now.  I don't see why we shouldn't
> >>>>> let
> >>>>> people turn them off if they want to.
> >>>>
> >>>> I think for now we should dump them all to disk and then allow
> >>>> them to
> >>>> assemble the user.  I don't think were sophisticated enough yet
> >>>> to help
> >>>> users understand the difference.  One can refer to them as options
> >>>> available for later configuration (disk bloat) and options for
> >>>> runtime
> >>>> configuration (memory bloat). I'd leave it simple for now.
> >>>>
> >>>>> david jencks
> >>>>>
> >>>>>> Joe
> >>>>>>
> >>>>>> Dave Colasurdo wrote:
> >>>>>>> Erik Daughtrey wrote:
> >>>>>>>> Dave, Thanks for the comments...
> >>>>>>>>
> >>>>>>>> I made comments below.  Would you create installer
> >>>>>>>> component  JIRAs
> >>>>>>>> for the items that make sense?
> >>>>>>>
> >>>>>>> Yep.  BTW, has it been decided if the installer is a 1.0.1
or
> >>>>>>> 1.1
> >>>>>>> item?
> >>>>>>>
> >>>>>>>>  On Thursday 19 January 2006 17:02, Dave Colasurdo wrote:
> >>>>>>>>> Looks like the Installer has made quite a bit of
> >>>>>>>>> progress.   Thanks
> >>>>>>>>> Erik!!
> >>>>>>>>>
> >>>>>>>>> I'd like to suggest a few Usabality changes to the
current
> >>>>>>>>> installer..
> >>>>>>>>> I'm sure you are already aware of many of these
and have
> >>>>>>>>> plans  to
> >>>>>>>>> update
> >>>>>>>>> them.  Just wanted to provide some input based on
my first
> >>>>>>>>> impression.
> >>>>>>>>> BTW, I've attempted to provide input based on my
thoughts
> >>>>>>>>> on how
> >>>>>>>>> this would be perceived from the perspective of
a first
> >>>>>>>>> time user.
> >>>>>>>>>
> >>>>>>>>> *Package Selection Panel*
> >>>>>>>>> 1)The available selections are really a hierarchy
> >>>>>>>>>   -Server
> >>>>>>>>>   --J2EE Features
> >>>>>>>>>   ---Jetty Web Container
> >>>>>>>>>   ----Jetty Sample Applications
> >>>>>>>>>
> >>>>>>>>>   ---Tomcat Web Container
> >>>>>>>>>   ----Tomcat Sample Applications
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Does Izpack allow you to capture the hierarchy graphically?
> >>>>>>>>
> >>>>>>>> Not that I've seen.  It looks like it's strictly a list
box.
> >>>>>>>>
> >>>>>>>>> If not, anyway to insert padding to the front of
entries to
> >>>>>>>>> show  the
> >>>>>>>>> hierarchy to the user?  I think this would be a
better
> >>>>>>>>> solution
> >>>>>>>>> than the
> >>>>>>>>
> >>>>>>>> Inserting spaces is something worth trying.
> >>>>>>>
> >>>>>>> I experimented with inserting spaces in front of the pack
> >>>>>>> names  and it
> >>>>>>> seemed to work fine. As expected, this also requires that
all
> >>>>>>> references
> >>>>>>> to the pack name in geronimo-izpack.xml, izpack-process.xml
and
> >>>>>>> izpack-user-input.xml need to be updated.  This results
in a
> >>>>>>> panel
> >>>>>>> that seems to show the hierarchy visually.  Though adding
> >>>>>>> the  spaces
> >>>>>>> for each element in the xml files is a real hack and does
 seem
> >>>>>>> troublesome. There should be an easier way to accomplish
this
> >>>>>>> without  unnaturally padding or creating a custom panel.
> >>>>>>> I'll  post
> >>>>>>> a question on this subject on the izpack mailing list.
> >>>>>>>
> >>>>>>>>> "Dependencies" box and would more clearly convey
the
> >>>>>>>>> relationship
> >>>>>>>>> between selections.  Also, we should remove the
> >>>>>>>>> dependencies box
> >>>>>>>>> and the
> >>>>>>>>
> >>>>>>>> I don't think it's possible to remove the dependencies
box
> >>>>>>>> and  keep
> >>>>>>>> the overall look and feel.
> >>>>>>>
> >>>>>>> Will also post this on the izpack mailing list.  Are they
> >>>>>>> responsive
> >>>>>>> to suggestions?
> >>>>>>>
> >>>>>>>>> other righthand box that contains the Logo.  The
> >>>>>>>>> description box
> >>>>>>>>> should
> >>>>>>>>
> >>>>>>>> I agree that the 2nd graphic is redundant at this point.
> >>>>>>>> However,
> >>>>>>>> one thing we have not explored is the fact that the
 graphic
> >>>>>>>> on the
> >>>>>>>> right is actually different for each pack although 
for now
> >>>>>>>> each is
> >>>>>>>> a distinct instance of the same bitmap.  There is  the
> >>>>>>>> potential to
> >>>>>>>> enhance each bitmap - possibly by making the  Geronimo
image
> >>>>>>>> subdued
> >>>>>>>> while overlaying something related to the  pack.  I
have not
> >>>>>>>> tried
> >>>>>>>> removing the graphic, but I don't think  it's possible
to
> >>>>>>>> remove it
> >>>>>>>> and keep this look and feel.
> >>>>>>>>
> >>>>>>>>> be located directly to the right of the main selection
box OR
> >>>>>>>>> below it
> >>>>>>>>> on the left.
> >>>>>>>>
> >>>>>>>> I doubt that this is easy to change.  We can look into
> >>>>>>>> making  some
> >>>>>>>> of these changes in more detail at some point.  Anything
is
> >>>>>>>> actually possible depending on the capabilities of IzPack
> >>>>>>>> itself
> >>>>>>>> and how much we're willing to diverge the Geronimo installer
> >>>>>>>> from
> >>>>>>>> the IzPack codebase.  It may actually be possible to
make
> >>>>>>>> some of
> >>>>>>>> the changes without changing IzPack, but based on what
I
> >>>>>>>> know  right
> >>>>>>>> now, I don't think so.
> >>>>>>>> We've already diverged from the IzPack codebase and
we need to
> >>>>>>>> factor these changes into IzPack as we move forward
or we
> >>>>>>>> may run
> >>>>>>>> into problems related to these changes later as IzPack
itself
> >>>>>>>> diverges.  I'm struggling a little with this at this
point
> >>>>>>>> given
> >>>>>>>> that IzPack is a generalized installer and some of the
> >>>>>>>> changes  made
> >>>>>>>> are specific to Geronimo.  I tried to keep the changes
> >>>>>>>> separated,
> >>>>>>>> but our requirements are reflected in code I wanted
to  keep
> >>>>>>>> generalized anyway. I don't want to boil the ocean,
but I'd
> >>>>>>>> also
> >>>>>>>> like to minimize problems occurring from the two distinct
> >>>>>>>> dev paths
> >>>>>>>> as much as possible.  Graphical look and feel changes
 might
> >>>>>>>> be less
> >>>>>>>> painful to push back into IzPack, but it's still a 
little
> >>>>>>>> worrisome.
> >>>>>>>>
> >>>>>>>>> I like the way the dependant boxes interact (turning
off
> >>>>>>>>> something
> >>>>>>>>> at the top of the hierarchy automatically trickles
down to the
> >>>>>>>>> dependant choices)..
> >>>>>>>>>
> >>>>>>>>> 2) It seems that we are allowing the user to choose
two web
> >>>>>>>>> containers?
> >>>>>>>>>     I thought we would limit the choice to just
one?
> >>>>>>>>
> >>>>>>>> The operator can install both containers, but they cannot
> >>>>>>>> activate
> >>>>>>>> both at runtime.
> >>>>>>>
> >>>>>>> For simplicity, I'd prefer to limit them to one web
> >>>>>>> container.  I
> >>>>>>> would think this is what 95% of users would want. I think
it is
> >>>>>>> confusing for a user to install two web containers and keep
one
> >>>>>>> disabled.  Isn't  the installer targeted for a novice user
> >>>>>>> and not a
> >>>>>>> sophisticated user  that wants to swap containers on the
> >>>>>>> fly.  Awhile
> >>>>>>> back we had binary images with multiple web containers and
it
> >>>>>>> caused
> >>>>>>> lots of  confusion with users.
> >>>>>>>
> >>>>>>>>> 3) It seems that it is currently possible to pick-and-choose
> >>>>>>>>> selections
> >>>>>>>>> that result in a server that won't start.  We need
to
> >>>>>>>>> decide which
> >>>>>>>>> choices are valid and assure that the resulting
> >>>>>>>>> installations  all
> >>>>>>>>> work.
> >>>>>>>>>    Flexibility is great, but we don't want to give
users the
> >>>>>>>>> ability to
> >>>>>>>>> choose non-working installations.
> >>>>>>>>
> >>>>>>>> The intent is to prevent the building of a non-working
server.
> >>>>>>>> There's only one instance I'm aware of that will result
in
> >>>>>>>> problems
> >>>>>>>> and it will be fixed soon.  If daytrader is selected,
 with no
> >>>>>>>> database, then obviously there will be problems.  David
> >>>>>>>> Jencks has
> >>>>>>>> suggested that we just go ahead and install Derby when
 the
> >>>>>>>> J2EE
> >>>>>>>> Features are selected -- and I plan to do this.
> >>>>>>>> If you're aware of other instances please enumerate
them...
> >>>>>>>
> >>>>>>> My initial selections produced a server that wouldn't start.
> >>>>>>> I'll go back and retry a few permutations to see if it is
> >>>>>>> different
> >>>>>>> than
> >>>>>>> what you described.
> >>>>>>>
> >>>>>>>>> 4) The available disk space seems to only be specified
for
> >>>>>>>>> "Server".  I
> >>>>>>>>> assume the other selections will eventually be updated.
> >>>>>>>>
> >>>>>>>> IzPack only displays this for packs which have files
> >>>>>>>> associated.
> >>>>>>>> This is one of the current issues about the installer.
It
> >>>>>>>> installs
> >>>>>>>> everything.  This will be addressed.
> >>>>>>>>
> >>>>>>>>> 5) Should the "Server" selection  be re-labeled
as
> >>>>>>>>> Geronimo  kernel
> >>>>>>>>> or Geronimo base infrastructure or something to
better
> >>>>>>>>> reflect what
> >>>>>>>>> it is?
> >>>>>>>>
> >>>>>>>> I don't have a real opinion on this.
> >>>>>>>>
> >>>>>>>>> 6) The "Greyed out packs are required" comment is
somewhat
> >>>>>>>>> confusing..
> >>>>>>>>> Perhaps just adding the word (Required) next to
the server
> >>>>>>>>> selection and
> >>>>>>>>> removing the other comment would be clearer.
> >>>>>>>>
> >>>>>>>> IzPackism. Fixing this would require overriding the
> >>>>>>>> ImgPacksPanel.
> >>>>>>>>
> >>>>>>>>> *Base Configuration Panel/Web Container Panel*
> >>>>>>>>> 7) Not sure I understand the "Active at runtime"
selections
> >>>>>>>>> and
> >>>>>>>>> how they
> >>>>>>>>> differ from the selections I've already made on
the "Package
> >>>>>>>>> Selection
> >>>>>>>>> Panel".. Is the idea that the package selection
identifies
> >>>>>>>>> which
> >>>>>>>>> packages get physically laid down on the target
machine and
> >>>>>>>>> "Active at
> >>>>>>>>> runtime" determines which of these are configured
as initially
> >>>>>>>>> enabled?
> >>>>>>>>> Not sure how common it would be to select a component
and then
> >>>>>>>>> specify
> >>>>>>>>> that it is disabled.  Is it more appropriate to
assume all
> >>>>>>>>> choices
> >>>>>>>>> are
> >>>>>>>>> enabled at installation and any disabling shoud
be done
> >>>>>>>>> directly
> >>>>>>>>> in the
> >>>>>>>>> resulting installtion (perhaps via the admin console).
> >>>>>>>>
> >>>>>>>> The installer is reflecting some some of the capabilities
of
> >>>>>>>> Geronimo.  I posed this question to the list a while
back. The
> >>>>>>>> response I received was that this type of behavior would
be
> >>>>>>>> desirable.
> >>>>>>>
> >>>>>>> I think we should discuss the issue a bit more with the
> >>>>>>> community.
> >>>>>>> From a *user  perspective* , how common will it be to  install
a
> >>>>>>> component (aka pack) and then want it disabled in the  resulting
> >>>>>>> installation. Installation should be about installing a
 simple
> >>>>>>> working configuration.  Uncommon configuration options
> >>>>>>> (install and
> >>>>>>> disable) shouldn't be a mainline choice in the  installer.
> >>>>>>> Advanced
> >>>>>>> configuration should be done after the server  is installed
> >>>>>>> (e.g via
> >>>>>>> the adminconsole or by updating xml files).   I found the
> >>>>>>> separate
> >>>>>>> "active at runtime" panels to be a bit  confusing and suspect
> >>>>>>> it will
> >>>>>>> cause confusion with novice users.
> >>>>>>>
> >>>>>>>>> 7.5) The Web container "Active at runtime" selections
are
> >>>>>>>>> greyed
> >>>>>>>>> out by
> >>>>>>>>> default when the Tomcat container is selected. 
Seems the
> >>>>>>>>> default
> >>>>>>>>> should
> >>>>>>>>> be enabled.
> >>>>>>>>
> >>>>>>>> Bug. Fixed now. JIRA 1505.
> >>>>>>>>
> >>>>>>>>> *Configuration Checkpoint Panel*
> >>>>>>>>> 8) Is it possible to place a confirmation summary
of all the
> >>>>>>>>> selections
> >>>>>>>>> and their size on this panel?
> >>>>>>>>
> >>>>>>>> The summary is possible. The sizes might be interesting.
> >>>>>>>>
> >>>>>>>>> *Installation Progress Panel*
> >>>>>>>>> 9) Probably want to pretty this Panel up with a
Title such as
> >>>>>>>>> "Installing Geronimo components".
> >>>>>>>>
> >>>>>>>> I figured this panel needed a little work.
> >>>>>>>>
> >>>>>>>>> 10) The installation panel seems to hang for awhile
even
> >>>>>>>>> after the
> >>>>>>>>> progress bar indicates completion.  Eventually the
"next"
> >>>>>>>>> selection is
> >>>>>>>>> available.  Is this a pblm with izpack?  Any chance
of
> >>>>>>>>> getting a
> >>>>>>>>> "completed message" in Big letters on the panel?
> >>>>>>>>
> >>>>>>>> Packs installation?
> >>>>>>>> It would not be trivial to change the packs installation
panel.
> >>>>>>>>
> >>>>>>>>> *Processing Panel"
> >>>>>>>>> 11) I had initially assumed the installation was
now done
> >>>>>>>>> and was
> >>>>>>>>> surprised that there was still more installation
steps to
> >>>>>>>>> be done.
> >>>>>>>>> Perhaps just a title on this Page "Installing Geronimo
> >>>>>>>>> configurations".
> >>>>>>>>
> >>>>>>>> Processing Panel is an IzPackism.  Changing the title
is not
> >>>>>>>> trivial. It's possible that something might be done
though.
> >>>>>>>>
> >>>>>>>>> 12) Would be nice to have "Configuration completed
> >>>>>>>>> successfully" or
> >>>>>>>>> "Configuration failed" message at the end of the
output.
> >>>>>>>>> Perhaps
> >>>>>>>>> this is
> >>>>>>>>> just adding the word "successfully" to your existing
message.
> >>>>>>>>
> >>>>>>>> That's easy to add to the text being inserted into the
> >>>>>>>> processing
> >>>>>>>> panel text box by the ConfigInstaller run.
> >>>>>>>>
> >>>>>>>>> 13) I see that the installer allows a user to create
an
> >>>>>>>>> automatic
> >>>>>>>>> installation script.  Is this a response file that
can be
> >>>>>>>>> used  to
> >>>>>>>>> invoke
> >>>>>>>>> the installer silently?
> >>>>>>>>
> >>>>>>>> Yes, just supply the name of the xml saved as an argument
to
> >>>>>>>> the
> >>>>>>>> installer.
> >>>>>>>>
> >>>>>>>>> 14) I like the fact that you provided a default
> >>>>>>>>> installation that
> >>>>>>>>> doesn't require any selections other than accepting
the
> >>>>>>>>> license.
> >>>>>>>>> Just
> >>>>>>>>> hitting next->next->next..  Joe's mom will
appreciate
> >>>>>>>>> that.  :)
> >>>>>>>>
> >>>>>>>> I want to cruise Joe's mom's web site when she's done
:)
> >>>>>>>>
> >>>>>>>>> Hope these comments aren't too nitpicky..  I think
the
> >>>>>>>>> installer is
> >>>>>>>>> really shaping up nicely. Sometimes minor changes
to panels
> >>>>>>>>> make  big
> >>>>>>>>> differences in a user's first impression..
> >>>>>>>>>
> >>>>>>>>> Thanks
> >>>>>>>>> -Dave-
> >>>>>>
> >>>>>> --
> >>>>>> Joe Bohn
> >>>>>> joe.bohn at earthlink.net
> >>>>>>
> >>>>>> "He is no fool who gives what he cannot keep, to gain what he
> >>>>>> cannot
> >>>>>> lose."   -- Jim Elliot
> >>>
> >>> --
> >>> Regards,
> >>>
> >>> Erik

-- 

Regards,

Erik

Mime
View raw message