Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: User Friendliness
Date: Fri, 8 Aug 2003 10:29:37 -0700
Message-ID: 
 <D129C739829DD411855A00E018C42729B51905@server01.carlsbad.chatspace.com>
Thread-Topic: User Friendliness
Thread-Index: AcNd0WSvQiaglpYbSDmiZHs0AEXIjwAAOJ5Q
From: "Nicholas Barratt" <nbarratt@akiva.com>
To: <geronimo-dev@incubator.apache.org>

Of course, for even more friendly configuration deployment, you don't
want to have to build at all!  Supporting unpackaged jars/rars/ears/etc
is part of the equation.  The other part (which I haven't seen in the
past) is to allow an archive to be replaced by a pointer file.  This
would alow me to have each of my J2EE components in a seperate project
with no build step at all!  Just update and go.

-----Original Message-----
From: Chris Opacki [mailto:chris_opacki@yahoo.com]
Sent: Friday, August 08, 2003 10:20 AM
To: geronimo-dev@incubator.apache.org
Subject: Re: User Friendliness


Good call! All of those issues are extremely familiar.
Maybe we could hook in some cvs functionality to the
configuration tools.

--- Erin Mulder <meara@alumni.princeton.edu> wrote:
> From: "Chris Opacki" <chris_opacki@yahoo.com>
> > Configuration file control is always an issue..
> Can't
> > win...just deal. I've always had separate config
> files
> > for different environments. Just something you
> have to
> > live with.
>=20
> Well, I'll agree that most developers are going to
> have locally modified
> config files, but that doesn't preclude all version
> control.
>=20
> For example, a couple of weeks into a typical J2EE
> project, I might get
> around to hooking up a security manager.   Ideally,
> the rest of the team
> should be able to pick that up in a CVS update/merge
> and run an Ant target
> to refresh their server config files, rather than
> having to manually update
> each of them.
>=20
> This sort of process works well with JBoss, but
> doesn't work with WebLogic.
> If we avoid casually reorganizing/reformatting
> config files, there's no
> reason it shouldn't work with Geronimo.
>=20
> The idea is to help people avoid those long Monday
> morning emails that go
> something like: "I checked in code over the weekend
> that relies on these 67
> configuration changes.   You won't be able to deploy
> until you cut and paste
> each of the snippets below into the relevant config
> file."
>=20
> Instead, that becomes, "Don't forget to update and
> run the 'copy-config'
> target this morning to get the latest security
> changes".   Much better for
> productivity and the overall frustration level.
>=20
> And then, of course, coherent version control on
> config files for shared
> dev/test/prod servers is a very good thing.   When
> you're diagnosing a
> problem, being able to use CVS diff to see that Bob
> changed thread pool
> sizes on Thursday and Sue changed the transaction
> timeout on Friday can save
> a lot of time.
>=20
> Bottom line is that Geronimo mgmt tools will be most
> useful if they don't
> mangle everything they touch, so this should be
> considered when choosing a
> synchronization framework.
>=20
> Erin
>=20


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com