The Artima Developer Community
Sponsored Link

Weblogs Forum
The Reasons behind Installer DeLux

8 replies on 1 page. Most recent reply: Jun 9, 2004 11:50 PM by Joe Cheng

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 8 replies on 1 page
Dale Asberry

Posts: 161
Nickname: bozomind
Registered: Mar, 2004

The Reasons behind Installer DeLux (View in Weblogs)
Posted: Jun 7, 2004 11:28 AM
Reply to this message Reply
Summary
Why not just use the installers already out there for crying out loud??!!
Advertisement

Intro

First, a couple observations about "installation":

  1. Installers are little more than glorified scripts.
  2. Providing an installer fulfills part of the follow-through for The Principle of "It Just Works!"
  3. I have issues...

Issues

  • Don't want to pay for commercial installers. Every project needs one which suggests that installer-like products are ripe for open source.
  • Commercial installers are too complex for simple installs. I think this is a direct result of marketing driven software releases.
  • The Open Source products that I found have NIH syndrome and look amateurish.

Itches Scratched

  • I want to integrate through standard cross-platform mechanisms->Java, Web Start(JNLP) and Ant!
  • I want to pull GUI code away from business code. XUL provides the GUI while AOP encapsulates component interaction with business code.
  • I want the installer to look professional.
  • I want the installer-developer "feedback cycle" to be as fast as possible. Script the GUI and the logic while the installer is running and have the changes display immediately.

Current Status

  • The home page has absolutely no project documentation.
  • The API is well documented, but it has no user documentation.
  • Ant is not yet integrated (next on my task list).
  • The installer-developer "feedback cycle" is not as short as I'd like it to be.
  • Needs more unit tests (yes, I know, I should've been doing it diligently from the start)
  • It works, in a very "alpha" sort of way
  • Total effort expended about 80 hours!

If you'd like to participlate, https://install-delux.dev.java.net/servlets/ProjectMembershipRequest (membership with java.net required).


David Terrell

Posts: 3
Nickname: dbt
Registered: Mar, 2004

Re: The Reasons behind Installer DeLux Posted: Jun 7, 2004 3:17 PM
Reply to this message Reply
I know that this isn't hip or cool, but if you actually want people to use it, I wouldn't actually use AOP. My java development is currently on hiatus, but if I were looking for an open source java installer (and I was, 6 months ago), I would have closed the browser frame as soon as I saw "AOP."

Dale Asberry

Posts: 161
Nickname: bozomind
Registered: Mar, 2004

Re: The Reasons behind Installer DeLux Posted: Jun 8, 2004 6:28 AM
Reply to this message Reply
> I know that this isn't hip or cool, but if you actually
> want people to use it, I wouldn't actually use AOP. My
> java development is currently on hiatus, but if I were
> looking for an open source java installer (and I was, 6
> months ago), I would have closed the browser frame as soon
> as I saw "AOP."

Ok... I'd appreciate more details about your concerns. Otherwise, I'll consider this a troll and have the site owner remove your message.

Joe Cheng

Posts: 65
Nickname: jcheng
Registered: Oct, 2002

Re: The Reasons behind Installer DeLux Posted: Jun 8, 2004 7:37 AM
Reply to this message Reply
I don't think the previous poster was trolling... many developers might be a little nervous to trust code that they've worked hard to stabilize on an installer that uses AOP, which not everyone agrees is ready for prime time.

As if to prove my point, this is what I got when I tried to install Judy:

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.continueLaunch(Unknown Source)
at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassFormatError: Invalid index 0 in LocalVariableTable \
in class file delux/installer/InstallerFunctionalAspects
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at com.sun.jnlp.JNLPClassLoader.defineClass(Unknown Source)
at com.sun.jnlp.JNLPClassLoader.access$100(Unknown Source)
at com.sun.jnlp.JNLPClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at com.sun.jnlp.JNLPClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at delux.installer.Install.main(Install.java)
... 11 more


I'm using Sun's JDK 1.5.0-beta-b32c (although I also have JDK 1.4.2_03 installed--I thought JWS is smart enough to pick the right JVM?).

Dale Asberry

Posts: 161
Nickname: bozomind
Registered: Mar, 2004

Re: The Reasons behind Installer DeLux Posted: Jun 8, 2004 9:20 AM
Reply to this message Reply
The problem is in my JNLP file:
<j2se version="1.4+" />

When I originally created it, I didn't know that 1.5 would use a different class file format. In other words, this is NOT an AOP problem but a configuration problem for JWS.

However, I still consider the original poster a troll since he didn't back up his argument with anything other than rhetoric. Where are the facts? What is wrong with AOP (besides someone's opinion) and why shouldn't it be used in the project? Many "experts" have the opinion that Java generics are bad. What if I use them in an upcoming version? Would that make the project any less viable?

If I had named the file InstallerMethodContractEnforcer and did not publicly announced the use of AOP, would anyone be the wiser?

The reason I mentioned the technologies being used was to recruit developers. If they don't use AOP, regardless of their reasons, they wouldn't be a good fit for the project.

Joe Cheng

Posts: 65
Nickname: jcheng
Registered: Oct, 2002

Re: The Reasons behind Installer DeLux Posted: Jun 8, 2004 2:50 PM
Reply to this message Reply
While it's true that modifying your JNLP to prevent 1.5 from running your app would have prevented this exception, the reason it doesn't work with 1.5 in the first place is because of your AOP bytecode:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=57436

The exact fear that I have heard people express about AOP implementations like AspectJ is its heavy bytecode emitting/manipulation. (Or was it about JDO?) I'm not an expert in Java class file formats but it does seem like a very easy thing to get wrong.

Apparently the ajc included with AspectJ 1.2rc1 fixes this problem. But that doesn't change the fact that there is a nonzero risk in using AOP or any other relatively new and un-mainstream technology.

I don't personally have an opinion as to whether you should be using XUL, AOP, or EJB (well, maybe that last one) in your installer. But I could understand someone being turned off by the AOP dependency.

Also I think the previous poster might've been implying you're mainly using AOP because it's "hip" and "cool"... I'd be interested in hearing a response to that.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: The Reasons behind Installer DeLux Posted: Jun 8, 2004 5:11 PM
Reply to this message Reply
It seems more sensible to focus on goals rather than implementation details. Goals like simplicity, robustness, ease of debugging, quality of logging etc., rather than details like whether you're using XUL, AOP, ABC, XYZ and WTF technolgies. By the way, I'm not sure what your install script file format is (eg. how to specify "copy this file to here and that file to there"), but if it is XML syntax, I'm not interested (if it is something like Python syntax, however, that's another thing...)

It looks like there are a ton of installers on SourceForge. This is the case for most software tools that don't require domain knowledge: they are overwhelming choice for developers with free time. Based on the comments above, I really don't see any impetus for DeLux other than tinkering with some things like AOP and XUL. I also don't see how you've credibly addressed the NIH issue by starting yet another installer project.

I agree with some of the comments about commercial installers, particularly with respect to the 5-ton gorilla InstallSheild. It is way too huge and unnecessarily complicated.

It is kind of funny how Microsoft has (almost) come full circle on this. After creating and promoting a huge amount of complexity with the registry, shared dlls, COM and the concomittant complexity of installations, they're now trying to tout the concept that .NET apps can be made to be done with a simple "Xcopy installation". Just copy all the files (including configuration files) to one directory and run the app. I've always liked (and strove to create) apps that work this way. The funny thing is, it doesn't take any special technology at all, it is just a matter of attitude.

Dale Asberry

Posts: 161
Nickname: bozomind
Registered: Mar, 2004

Re: The Reasons behind Installer DeLux Posted: Jun 9, 2004 8:30 AM
Reply to this message Reply
>> It seems more sensible to focus on goals rather than implementation details.<<

That was the purpose of the "Issues" and "Itches Scratched" sections (see below). The comments explaining my goals are in bold. The comments referring to the technologies used are in italic.

>>
Issues

* Don't want to pay for commercial installers. Every project needs one which suggests that installer-like products are ripe for open source.
* Commercial installers are too complex for simple installs. I think this is a direct result of marketing driven software releases.
* The Open Source products that I found have NIH syndrome and look amateurish.


Itches Scratched

* I want to integrate through standard cross-platform mechanisms->Java, Web Start(JNLP) and Ant!
* I want to pull GUI code away from business code. XUL provides the GUI while AOP encapsulates component interaction with business code.
* I want the installer to look professional.
* I want the installer-developer "feedback cycle" to be as fast as possible. Script the GUI and the logic while the installer is running and have the changes display immediately.
<<

You can see that I put very little emphasis on the technology. I put the technology comments in there to show how they help(ed are helping) me achieve those goals.

>>By the way, I'm not sure what your install script file format is (eg. how to specify "copy this file to here and that file to there"), but if it is XML syntax, I'm not interested (if it is something like Python syntax, however, that's another thing...)<<

Luxor XUL is the XUL framework I've chosen. The GUI is (of course) defined with XML tags. The Luxor libraries support scripting in Python ;-) and BSH with future support for Groovy. However, I'm also integrating Ant since it can be used by a wider audience, as well as, it has many pre-built components for doing high-level file system like things needed by an installer.

>>It looks like there are a ton of installers on SourceForge.<<

Yeah, I investigated many of those. Almost all of them seem to be abandoned. The very few remaining are significantly incomplete (like mine :-) or don't address my issues or scratch my itches.

>> I really don't see any impetus for DeLux other than tinkering with some things like AOP and XUL<<

Apparently you don't have the same itches as me. That's Ok. As for AOP, I've been working with that since pre 0.9! I discovered XUL a year or two ago and am now a Luxor contributor. So, for me, I'm well past tinkering when it comes to those two technologies. I have a solid understanding of what I can use them for and believe that they can be leveraged better than other technologies for scratching these itches.

>>I also don't see how you've credibly addressed the NIH issue by starting yet another installer project.<<

Possibly. However, my original approach was to work on a couple of the most promising F/OSS installers. When I would suggest doing something like adding Ant support, I was shot down every time! I was willing to donate the work and they said "no." Screw them - I'll do it myself.

>>I've always liked (and strove to create) apps that work this way.<<

That's an admirable philosophy. I see the purpose of an installer as a way to walk the user through the configuration of a complex application. In particular, one of my projects is a Jini-based application. (Un)fortunately, Jini has a gazillion configuration options that can be set or used. An installer can limit these options in such a way that is appropriate for a newbie while leaving the other options accessible through other methods. My belief is that if I make it easier for anyone (newbie or expert) to get started, the more value it will provide to them. Maybe this is a corollary to your ideas?

For a little more background to this, check out The Richmond Post: Luxor XUL Titan Interview: R. Dale Asberry at http://xul.sourceforge.net/post/2004/05/luxor_xul_titan_interview_r_dale_asberry.html

Joe Cheng

Posts: 65
Nickname: jcheng
Registered: Oct, 2002

Re: The Reasons behind Installer DeLux Posted: Jun 9, 2004 11:50 PM
Reply to this message Reply
Thanks for the details, Dale. I hadn't heard of Luxor, sounds interesting... I'll be sure to check it out.

Flat View: This topic has 8 replies on 1 page
Topic: Get thee behind me, Satan Previous Topic   Next Topic Topic: Experiences On Running A Website For Profit, Part 2: Keep 'Em Coming

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use