That's a good write up and I think all 4 of those options could be a
valid approach, but one thing to remember is that I don't think that any
one option below negates any of the other options. I actually think
that we could probably provide all of them (if we really wanted too).
That being said, we still need a default or standard install option and
IMO #1 is the best balance between simplicity for users and developers.
I am 50/50 on #2 and the installer idea. I don't have a problem with it
since it doesn't negate using #1 as the default option, but somehow I
see it as being more trouble than it's worth. It could take a fairly
significant amount of code to develop a proper installer for each
platform and you have to remember that it's not just installations which
you have to account for, it's upgrades as well, and that means the you'd
have to touch the installer for each release which could be a pain.
I think #3 is a pretty nice idea for people who just want to evaluate
Roller or are going to do a really simple/personal install, and like #2
it doesn't negate any of the other options.
I definitely wouldn't want to have Roller be responsible for interacting
with various web containers as part of the installation, so for that
reason I don't like #4.
So my vote would be for #1, with #2 and #3 being optional offerings for
any containers that someone wanted to write/maintain them for.
-- Allen
Dave wrote:
The Roller installation process is unacceptably complex and I'd like
to fix that. I've been thinking about the problem for a couple of
weeks now and I've talked to folks in Sun, at ApacheCon and JavaOne
about the problem. I looked at configuration features in Tomcat and
Glassfish. I also looked at installation instructions for popular Java
webapps Confluence, JIRA, Liferay Portal and Blojsom.
So far, I've identified four these options:
1) Property file based configuration
- User puts JDBC and mail-session connection parameters in
roller-custom.properties
- If no JDBC and mail-session properties are found, falls back to
JNDI resources
- Roller creates/upgrades tables as needed (prompts user 1st and
can be disabled)
Pros:
- Easy, just one properties file for all Roller configuration
Cons:
- User still has to do configuration if they want to use JNDI resources
2) Separate installer for each Servlet container / app server
- Installer prompts user for configuration parameters
- Installer does all setup and deploys Roller
- Roller creates/upgrades tables as needed (prompts user 1st and
can be disabled)
Pros:
- Easy UI driven installation
- Supports JNDI resources
Cons:
- Need to develop separate installer for each Servlet container / app
server
3) Standalone bundle with Roller, Servlet container / app server and
database
- User downloads, unpacks, runs startup script... done!
Pros:
- Amazingly easy for user
- We can steal creation script from Blogapps for the Roller, Derby,
Tomcat bundle
Cons:
- We'll need a separate bundle for each server
- Not a complete solution if user wants database other than one we bundle
4) Roller does completely handles it's own installation
- Roller prompts user for configuration parameters, does all setup
- Creating JNDI data-source and mail-session if needed
- Or creating property file for non-JNDI based installation
- Roller creates/upgrades tables as needed (prompts user 1st and
can be disabled)
Pros:
- Easy UI driven installation
- Does everything!
Cons:
- Need to develop separate logic for each Servlet container / app server
- May be difficult or impossible for some servers
- May require application server jars in Roller's WEB-INF/lib directory
Before I go further with my proposal, I'd like to get some feedback.
At this point, I'm learning towards doing both options #1 and #2.
Option #3 is too limiting and option #4 is just too complex.
- Dave
