quality@glassfish.java.net

Re: b25 lot better than the other promoted build

From: Judy Tang <Judy.J.Tang_at_Sun.COM>
Date: Sat, 20 Sep 2008 19:27:07 -0700

Thanks Chris for sharing your expertise with us !

Judy

Christopher Kampmeier wrote:

> Hi Survivant,
>
> Survivant wrote:
>
>> that's a good explaination.
>
>
> I should have stressed that our preference was to have created a
> Swing-based GUI from the start, but...
>
>>
>>> As I am certain you face in your development projects, practical
>>> technical dependencies, schedules and prudent choices all come into
>>> play while making directional decisions.
>>
>>
>> As the Jython developers note: "Don't rewrite
>>
>>> perfectly good Python code in Java
>>
>>
>> Agreed. I though that you start the update tool from scratch and
>> choose python over Java. I agreed to that Jython could be a good
>> move, but if there isn't a more value.. why waste time to do that.
>
>
> It will be good to use Jython when developers need a 100% Java solution.
>
> We don't have plans to migrate the existing Python-based GUI to run
> over Python, but Java apps that want to leverage pkg(5) directly via a
> Java binding will benefit from the option to run pkg(5) on a JVM.
> Since our initial recent tests with Jython 2.5 EA make it appear that
> it might be relatively straightforward to provide this optional
> JVM-based runtime stack.
>
> Porting the Update Tool 2 GUI to Swing doesn't make sense to the team
> at this stage. If a version 3 GUI entail a substantial UI redesign,
> I'm sure the team will consider a range of UI development toolkits
> including Swing and browser-based technologies.
>
>>
>> one question. Is it complex to switch to WebStart pack instead of
>> pkg for the installation ?
>
>
> I don't view them as addressing the same space, but if you're familiar
> with developing Java Web Start installers, you could probably cobble
> together a sample install app using the GF V3 Prelude pkg(5)-enabled
> zips pretty easily.
>
> Generally, we make a distinction between an initial install
> application and the ongoing addition of new packages and updating of
> installed packages. Technologies used to lay down an initial set of
> bits can be viewed as complementary to package management
> technologies. Sometimes the lines between these two worlds are
> blurred a bit as in the case of Java Web Start since it includes an
> overall application update feature.
>
> The good news is that one can use a wide array of technologies such as
> Java Web Start, OpenInstaller, IzPack, InstallShield, expansion of
> plain old zip and tar.gz archives, etc. to lay down a pkg(5)-enabled
> installation without really caring about also taking on the job of
> ongoing package additions and package updates. We feel this approach
> is valuable because it offers projects a great deal of choice as to
> the initial install technology yet lets the projects and their users
> benefit from a consistent set of ongoing install management
> interfaces. Even for the same bits, there can be multiple initial
> install approaches. We've seen this with GF V3 where there are
> OpenInstaller, IzPack and installerless zip archive approaches.
>
> Projects can wrap the ongoing install management pkg(5) interfaces in
> their own management apps and, if they want to do so, promote the use
> of the generic Update Tool GUI and its companion desktop notifier.
>
> There are examples of both IzPack and OpenInstaller laying down
> pkg(5)-enabled images. As we work with the OpenDS team to
> pkg(5)-enable their distributions, we'll be extending their use of
> Java Web Start to lay down the image. That might be the first example
> of marrying pkg(5) to Java Web Start. I expect it to be pretty simple
> because OpenDS is essentially delivering a zip within a Web Start
> wrapper. We'll just be pkg(5)-enabling that zip file.
>
> The built-in update facility of Java Web Start may or may not have
> much of a role to play when using pkg(5)-enabled installations. At a
> minimum, it could probably be used to help trigger an image-wide
> update form the pkg repositories. We'll get our feet wet as we look
> at the OpenDS Java Web Start example.
>
> Chris
>
>
>>
>> ----- Original Message ----- From: "Christopher Kampmeier"
>> <Christopher.Kampmeier_at_Sun.COM>
>> To: <dev_at_updatecenter.dev.java.net>
>> Cc: <quality_at_glassfish.dev.java.net>
>> Sent: Saturday, September 20, 2008 1:52 PM
>> Subject: Re: b25 lot better than the other promoted build
>>
>>
>>>
>>>
>>> Judy Tang wrote:
>>>
>>>> Thanks Survivant, it is great to hear this news from you. Thanks
>>>> developer, they worked very hard and fixed a lot of bugs.
>>>> I checked your long list of bugs, now only 5 are open :-)
>>>>
>>>> Let me cc to updatetool developer for your question/suggestion.
>>>>
>>>> Happy Fishcatting !
>>>> Judy
>>>>
>>>> Survivant 00 wrote:
>>>>
>>>>> - the locale error is fixed,
>>>>> - the blank page when admin gui is install is fixed (work for me)
>>>>> - no javascript error when accessing the admin gui
>>>>>
>>>>>
>>>>> one question. WHY the update tool is done in python and not Swing
>>>>> ? With swing, Glassfish won't have to install python.. and I don't
>>>>> see why not promoting Java technologies over python :(
>>>>
>>>
>>> As I am certain you face in your development projects, practical
>>> technical dependencies, schedules and prudent choices all come into
>>> play while making directional decisions.
>>>
>>> Since the Image Packaging System (aka pkg(5)) infrastructure is
>>> written in Python and there isn't a suitable Java->Python solution
>>> available, the choice was made back in early CY08 to go with a
>>> Python-based GUI framework to develop the standalone Update Tool GUI.
>>>
>>> Since the Java API for pkg(5) covers only a part of the pkg(5)
>>> Python API and this Java API was only recently introduced, using
>>> that API for a Swing-based GUI was not a practical option.
>>>
>>> Later this year we expect to continue experiments with the Jython
>>> 2.5 early access implementation to validate that running the pkg(5)
>>> Python code on top of a JVM will be feasible. Initial experiments
>>> bore some positive results, but more investigation is required.
>>>
>>> With the Jython approach, an evolution of the current Java API for
>>> pkg(5) would likely be mapped on top of the underlying Python
>>> implementation such that we can avoid completely reimplementing the
>>> pkg(5) infrastructure. As the Jython developers note: "Don't
>>> rewrite perfectly good Python code in Java!" i.e. Don't reinvent the
>>> wheel when technologies such as Jython exist.
>>>
>>> If later in CY09 people feel it's necessary to implement a
>>> Swing-based Update Tool GUI, then people will be better enabled to
>>> do so at that time. (Note that use of Jython introduces a dependency
>>> in terms of download size, but at least it's cross-platform).
>>>
>>> More generally, in terms of language choices, bear in mind that
>>> since the JVM has been promoted as a great runtime platform for
>>> scripting support, promotion of Java over Python or other scripting
>>> technologies isn't as material these days. It's all about using the
>>> right tool for the job.
>>>
>>> Chris Kampmeier
>>>
>>>
>>>>>
>>>>> I'm trying to install updatetool from the updatetool.bat.. but it
>>>>> stuck to python. I suppose that's why the Windows installer stall
>>>>> at 45%
>>>>>
>>>>> Installing: [pkg:/pkg_at_1.0.7,0-15.1183:20080912T012943Z]
>>>>> pkg:/pkg_at_1.0.7,0-15.1183:20080912T012943Z: downloading 206 files
>>>>> pkg:/python2.4-minimal_at_2.4.4.0
>>>>> <mailto:python2.4-minimal_at_2.4.4.0>,0-15.1183:20080912T012955Z:
>>>>> downloading 262 files
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_updatecenter.dev.java.net
>> For additional commands, e-mail: dev-help_at_updatecenter.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>