Hi David,
-----Original Message-----
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: mercredi 19 octobre 2005 20:20
To: dev@geronimo.apache.org
Subject: Re: [Daytrader] Converting to Maven 2
[snip]
- automated functional testing
Do you have some way to do this outside a j2ee server? If not, what
does this mean?
Yes, this is white box testing from outside. I'm planning to do this with
Cargo (which supports several containers).
- automated deployment to Geronimo or other container(s) (using Cargo)
Does cargo support jsr-88 yet?
Actually yes it does! :-) This is how I'm planning to automate
hot-deployment to Geronimo. This feature is in Cargo 0.7 (not released yet).
- ability to build for different target environments
What does this mean? IIUC the ear is supposed to be portable, and the
deployment plan is not included in the ear.
Two things here:
- yes it seems the EAR in Geronimo is portable with the deployment plan
being outside of the EAR. However this is not the case for other containers.
Also, there is still the deployment step which is environment-dependent: it
may not be the same plan to deploy for a development environment and for a
production one (for example you may want to use port 8080 in development and
port 80 in production, or better you may want to deploy on a single server
in development and on a cluster node in production, etc).
- the build will not consist only in building the J2EE archives but also in
the configuration files, database files, etc, which may be
environment-dependent.
I also know projects which do development using a container and deploy on
another one... (not that this is a good practice!).
- distribution of a packaged zip containing not only the EAR but also
the
container's configuration. This is to version control the container's
config
files and make the app "executable" and separated from the container's
install.
I'm not sure what you mean. We have a couple of possibly relevant
capabilities of which I will mention the maven 1 plugin to install a
geronimo instance and do stuff like start/stop it, deploy/undeploy
apps, etc.
Imagine a build that spans the full development lifecycle. What I've done in
the past is automate everything till the pre-production step. This means I'm
able to take the source code and build and deploy everything to the target
platforms. This includes container configuration files (I don't enough about
Geronimo yet but for WebLogic this means a domain configuration with all the
files that go there; for jboss that means a server configuration directory,
etc). The idea is that what is delivered is a zip representing a directory
with everything set up in the right place there so that the container can be
started in-place in that directory. The container config files are still
located where the container is installed but its configuration is located in
our directory. This allows redelivering easily the part that we want to
store in our SCM.
Maybe this does not apply to recent containers like Geronimo and maybe
Geronimo is flexible enough so that a full container config can be set up
from remotely. This is a strategy I have been applying between 2002 and
2004. It may be that since 2005 containers are configurable enough not to
require this anymore?
Here's a question: is it possible for example to remotely configure the
number of threads used by the ejb or servlet containers? Is it possible to
remotely control the location where logs files will go, etc?
In any case, there's still the need to not only package the J2EE modules but
also the configuration files (whether those files are installed locally or
through remote access). This makes up a distribution which can then be
installed manually by, say, a production team or through Maven (by using
deploy/undeploy stuff as you mention above).
- automate the database setup
This would be great. I think we need a generic solution for this
Agreed, although it'll have to be per-database type (unless someone comes up
with a generic API in the same manner as Cargo does for containers ;-)).
I'll do the derby one as it seems there are already some derby script for
the Daytrader app.
- possibly convert some of the daytrader app to use xdoclet to
demonstrate
how it works with Maven2
After thinking this through, I think I'm going to work in my own repo.
This
is the easiest and fastest solution for me. Once I have finished, I
can then
offer this full m2 build to the Geronimo project and you can decide to
do
whatever you want with it. I won't be touching much of the daytrader
source
files so it shouldn't be that hard to incorporate afterwards.
I think this is great, and would like to know more about what you are
up to. Please keep us informed!
Will do, thanks!
-Vincent
