I'm a little worried about trying to do db upgrades within the webapp, but
if we write this properly it won't have container dependencies and it won't
be hard to extract later if we decide we should.
[One of the nice things about using the dependency injection model is that
you write classes that can be in library jars that run equally well inside
or outside an app server container. Here for example, injecting the
DataSource versus looking it up using JNDI makes it a lot easier. It's easy
to write an adapter for the container setting that allows us to use JNDI to
look it up and then inject it; it's harder to run a class externally that
directly relies on JNDI to find the DataSource.]
--a.
----- Original Message -----
From: "Dave" <[EMAIL PROTECTED]>
To: <dev@roller.apache.org>
Sent: Thursday, May 17, 2007 6:09 AM
Subject: Re: Fixing the Roller installation process
On 5/16/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
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).
Yes, that's a good point.
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 think so too.
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 will need to develop a couple of these and I'd like to contribute
them to Roller.
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 intend to continue supporting the Blogapps Server, which includes
Roller, JSPWiki, Tomcat and Derby -- but I'm not going to propose
doing this for Apache Roller (yet).
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.
I agree.
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.
That's my current thinking as well.
- Dave
