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
