JBoss Mail Server M3-pre1

[acoliver]

So this is a bit more "pre" than the normal "pre" releases of the milestones. This is my first cut with the izPack installer. I'm busy integrating it into the build, but meanwhile I'd like Mike and hardcore users to give it a test. I appologize for the mammouth size, it includes JBoss 4.0.3 as well (the idea being that a realative simpleton who managed to get Java installed shouldn't have a problem). The next cut (pre2) will include a Java Web Start as well to make it a moronable install (if you don't have java, I think the browser will go to the plugin finder and you'll install Java -- 1.5 no doubt). See http://jira.jboss.com/jira/browse/JBMAIL-60 for details about the izPack install.

The install is here: http://wiki.jboss.org/wiki/attach?page=MailServicesMilestoneReleases%2Finstall-jbms-1.0m3-pre1.jar

BTW, I'm not going to announce this one to the wider audience ala jbossBlog because I want to get it on a better delivery mechanism. Ultimately, this stuff should tie to a larger JBoss-related installation system that can go grab what is needed (for instance the appserver) and customize only if necessary.

Note that the "automated install" appears to be broken in izPack.

-Andy

[acoliver]

Here is the Java Web Start version: http://jboss.sf.net/jnlp/jbms-1.0m3-pre1.jnlp

-Andy

[acoliver]

Okay everything is checked in. I need to do some doco and stuff but I consider that associated with doing doco and the release. There is also some minor "icons" and crap like that but I'll get that as part of the release as well. Mike, grab CVS and run the "dist" target. Also note that there is a new "dev" target and "dev-deploy". I included instructions inside of the build (regarding how to do dev builds). AFAIK this requires JBAS-4.0.3-rc2 (check out 40 branch from CVS) because I haven't tested with 4.0.2.

One goal was to not have multiple editions of jboss-service.xml and hibernate-service.xml so now those are placeholders and there are only the templates. You must now run the dist build at least once and get the ones you want (configured how you like) then stick those in src/dev. The goal is to make sure the installer continues to work and not just one person maintains it and that it is kept consistent. There WOULD be a better way to do this if it weren't for the problem with automated builds. Mkunwrapped is now a non-public target (do ant -projecthelp, I added descriptions).

Mike, I'd like your feedback in particular.

[mikezzz]

Hi Andy,

I had a quick go with the new installer. Looks good I think it is definitely the way forward. I didn't get a running version as I had some problems checking out 4.0.3 rc3 (cvs co jboss-4.0 gives you 5.0.0) and tried to make it work on 4.0.2, which doesn't seem to like exploded har files. Will get 4.0.3 this weekend and get it working.

A couple of comments, these are mostly cosmetic and pie in the sky stuff.

Choosing between a new or existing jboss install is a little clumsy. On the Installation location page it would nice to have 3 radio button options:

- New install, with text field and browse button.
- Existing install, with text field, browse button and select box indicating with server configuration to use (we could produce a list once the directory is selected). We could also default the jboss installation from the JBOSS_HOME environment variable if it exists.
- Create deployable EAR. Useful for deploying to headless servers/clusters.

The packages screen would be read-only as the above selection will dictate what pacages to use.

In the longer term it would be nice to support more advanced configurations and be able to set all of the options on all of the MBeans. E.g. being able to set options for performance tuning would be nice. Perhaps an "Advanded" button on some of the pages which shows more detailed options.

I also noticed that if you reinstall it over an existing install it fails. Something to do with keystore generation.

Mike.

[acoliver]

modules limit directories, you still need the tag

cvs co -r Branch_4_0 jboss-4.0

Choosing between a new or existing jboss install is a little clumsy. On the Installation location page it would nice to have 3 radio button options:

- New install, with text field and browse button.
- Existing install, with text field, browse button and select box indicating with server configuration to use (we could produce a list once the directory is selected). We could also default the jboss installation from the JBOSS_HOME environment variable if it exists.
- Create deployable EAR. Useful for deploying to headless servers/clusters.

I think you're on to something, but we'll have to defer that to a later milestone because it involves changes to izPack and probably coordination with the overall JBoss Build project. I'm sure scott/clan would be ameniable to this (since it has larger uses), but it involves too many touch points to get out for M3. (The installation panel is more or less a fixed panel)

In the longer term it would be nice to support more advanced configurations and be able to set all of the options on all of the MBeans. E.g. being able to set options for performance tuning would be nice. Perhaps an "Advanded" button on some of the pages which shows more detailed options.

Yes. I vacillate on this. We're going to need an admin tool so should the installer let you do that or require you to do that in the admin tool? My present thinking is that it should once automated install works properly so that you can install consistantly accross an organization. Though I have more sinsiter plans for MBeans and all.

I also noticed that if you reinstall it over an existing install it fails. Something to do with keystore generation.

I'll probably cover this in the readme. I don't want to mindlessly clobber an ssh key. It should work if you don't generate a new key.

=======

That stuff aside, are you cool with the dev and dev-deploy targets? I wanted to find a way to keep the install working consistantly. This will probably mean everyone has to grok just a little bit about izPack. I don't think groking the velocity templates is that hard (if one understands if statements and ant basically ;-) ). There are minor gotchas but one figures them out quickly (no ${foo.bar} type variable names mostly because it thinks the dot means class member)

[adrian.brock]

cvs co -r Branch_4_0 jboss-4.0

cvs co -r Branch_4_0 jboss-4.0.x

[acoliver]

I had a quick go with the new installer. Looks good I think it is definitely the way forward. I didn't get a running version as I had some problems checking out 4.0.3 rc3 (cvs co jboss-4.0 gives you 5.0.0) and tried to make it work on 4.0.2, which doesn't seem to like exploded har files. Will get 4.0.3 this weekend and get it working.

Oh mike, how come you didn't try letting the installer create your jboss? It has a copy in it?

[mikezzz]

I was wanting to check out the build dist stuff. Plus I got bored of downloading after waiting for the wrong version of JBoss to be checked out.

[acoliver]

ahh i get it now. checking out is slow for you? Do you use -z3 or better option? Its pretty speedy for me.

[mikezzz]

It's reasonable, but even with -z3 over 512K link it still takes some time. Also I was staying late at the office to download it as I didn't want to pay £5/hour to use the hotel's wireless.

[mikezzz]

BTW: I am happy with the dev/dev-deploy tasks, however it would be nice to have a task that ran the Velocity templates taking the variables from a properties file or similar. This would allow for a simple automated build-test task.

Mike.

[acoliver]

How come you're in a hotel?

[mikezzz]

160 mile round trip from home to the customer site (its a consultants life for me...), so I stay over a couple of nights a week. Its when I do most of my JBMail work.