This page exists to collect details of problems (and their solutions) in building or running a fresh copy of Geronimo. This is an add-on to the geronimo distribution file README.txt. The intention is that it will be the first port of call when such issues arise, and that developers will update it as problems/solutions are found. Hopefully it will become less necessary as Geronimo nears a formal release process.

First start with :

the default build process available in the Geronimo distribution file BUILDING.txt
a list of KnownWorkingConfigurations

Contents

Pre-requisites
For the impatient ...
New To Maven?
Building Geronimo and related projects
Building Offline
Build Just One Module
Building the specs
Building the Web Console
Compile Only
Cleaning your workspace
Testing the Build
Diagnosing a Failed Test
Bypassing Tests
Building from behind a firewall / proxy
- Windows
  - Setting up subversion to tunnel through proxy
  - Setting up maven to tunnel through proxy
Problems?
- Maven Build (or Dependency Download) Problems
- Tests fail with java.net.BindException : Address already in use: connect on Windows
- OpenEJB ITests fail with org.omg.CORBA.COMM_FAILURE on Windows
- Remoting Tests Hang
- Assembly Fails
- Assembly Hangs
- Assembly fails on Windows due to a forked process from a previous failed assembly attempt not being terminated
- Unable to obtain goal default – <home.dir>\.maven\cache\xmlbeans-maven-plugin-2.0.0-beta1\plugin.jelly:24:23:
Improved Maven IDEA plugin
Creating Intellij IDEA projects

Pre-requisites

J2SE SDK (http://java.sun.com/j2se/1.4.2/)
Apache Maven (Maven v. 1.1-beta-2).
Subversion 1.2.0 (http://subversion.tigris.org/) - any version greater than 1.0 should work well.
CVS. UNIX/Linux users typically have CVS. Windows users can get WinCVS from http://www.wincvs.org site.

For the impatient ...

... who want to work on a fresh checkout of all major geronimo-related projects in one maven build environment.

NOTE: OpenEJB's CORBA layer uses some classes that belong to sun.com.* package of Java 1.4. Because of this it's not yet possible to build OpenEJB and thus use the steps described in this section with Java 5.

Assuming you have Apache Maven 1.0.2+ installed, build the first time with:

$ svn checkout https://svn.apache.org/repos/asf/geronimo/trunk geronimo
$ cd geronimo
$ maven m:fresh-checkout
$ maven new

This builds j2ee-jetty-server and j2ee-tomcat-server in assemblies/j2ee-jetty-server and assemblies/j2ee-tomcat-server directory, respectively.

Next time you want to build Geronimo you do not need to run the checkout again, just run an update from the geronimo source directory:

```
$ maven m:update 
$ maven -o
```

The m:update gets new code from cvs/svn whereas maven -o builds them in the offline mode (without downloading the dependencies) using new goal. The "-o" flag tells Maven to build offline, which is much faster than the default online process. Occasionally, though, the offline build might fail if some dependency goes out of date; in that case you'll want to run maven new without the -o flag. See "Building geronimo and related projects on this page for further cures to build failures: -Dmaven.test.skip=true and/or -Dmaven.itest.skip=true).

Run the server with the debug console web application:

$ cd assemblies/j2ee-jetty-server/target/geronimo-1.0-SNAPSHOT
                    OR 
$ cd assemblies/j2ee-tomcat-server/target/geronimo-1.0-SNAPSHOT

$ java -jar bin/server.jar

(Please also check http://wiki.apache.org/geronimo/Running)

Connect to the default root page:

http://localhost:8080/

You should check back here occasionally as things may well change.

New To Maven?

You don't build this project with Ant (directly), you build it with Maven. Maven manages downloading all the external dependencies for you, as well as handling the large number of modules to build and then creating one consolidated Geronimo build based on that.

To start with, download maven from http://maven.apache.org/ then install it and put its bin directory on your path (or put a script to run it on your path or whatever).

Now to build (and test) Geronimo, go to the geronimo directory you checked out of svn and run maven (you must be online at the time, so Maven can download all the dependencies of Geronimo).

There are a variety of parameters and options you can pass to maven to affect how it builds. Some are listed in the topics below. If you run maven -g you will get a huge list of options, separated into categories. To use one, run "maven category:command", so to run the "compile" command in the "java" category, you'd run maven java:compile (and you can also add multiple commands to the command line).

If you have common options you always want to pass to maven, you can put them in a file called build.properties either in the directory you run maven from (to affect only that project) or your home directory (to affect everything you run maven for). See http://maven.apache.org/reference/user-guide.html#Behavioural%20Properties and http://maven.apache.org/apidocs/constant-values.html for some common property names.

For further reference on the available commands it may be a good idea to change into a subdirectory of geronimo/modules and have a look at the respective maven.xml files.

Building Geronimo and related projects

(see also GERONIMO-297)

To build geronimo and related projects at once in a unified environment, follow this procedure:

Edit project.properties and set the cvs info appropriately for any project you may be a committer on.

run maven m:checkout to get OpenEJB from cvs.

run maven m:build or just maven to build everything. There may be test failures in other projects, so you may need -Dmaven.test.failure.ignore=true. You might need to run twice to make sure all plugins are installed before they are used.

To prevent the itests from running in the openejb build, you need -Dmaven.itest.skip=true defined.

If the build fails in OpenEJB :: Integration Tests, try maven m:build -o -Dmaven.test.skip=true -Dmaven.itest.skip=true.

To remove the local maven repository artifacts of Geronimo, OpenEJB, and TranQL, do maven m:clean-repo – and build again.

Once the build successfully completes, the assembled server will be available in the target directories, i.e. geronimo/assemblies/j2ee-jetty-server/target/geronimo-1.0-SNAPSHOT and assemblies/j2ee-tomcat-server/target/geronimo-1.0-SNAPSHOT

In some cases synchronized changes are made to several of the projects at once, and you may have trouble building the HEAD code of Geronimo against the older binaries of OpenEJB. In that case, you can run: 1. To checkout OpenEJB

        $ maven m:co
        $ maven m:rebuild-all

The first command checks out the latest OpenEJB code, while the second cleans and previous build output and rebuilds Geronimo, OpenEJB from scratch. You can stop the build when you get to the assembly module, and certainly when you get to itests. 2. build the plugins explicitly:

      $ cd plugins
      $ maven -o multiproject:install
      $ cd ..

3. build the configs:

      $ cd configs
      $ maven -o multiproject:install
      $ cd ..

- This step uses the packaging plugin to build all the

configurations we need for both jetty and tomcat servers, and installs them in your local maven repo as .car files. 4. build the servers:

      $ cd assemblies/j2ee-jetty-server
                OR 
      $ cd assemblies/j2ee-tomcat-server

      $ maven -o clean default

Warning: The configIds of these configurations are incompatible with the configIds used by the previous assembly. If you deploy anything on these servers and you specify a parentId or an import you will have to modify them.

Building Offline

If you're not online (so Maven fails to download), use the -o flag to maven (i.e. run maven -o).

Build Just One Module

cd to the directory holding the module (i.e. modules/core) and run maven from there.

Alternately, set the "modules" system property to the name of the directory under "modules" or "specs" that you want to affect. For example, maven -Dmodules=core (for modules/core) or maven -Dmodules=j2ee-deployment (for specs/j2ee-deployment)

Building one module will not update the target/repository or target/lib (where the .jar's used to run Geronimo are located). To update the executable system, run maven in the modules/assembly directory, that will copy .jars from the maven repository into the target/lib and target/repository directories.

Building the specs

In order to build the specs sources you need to use Apache Maven 2.0 or later (http://maven.apache.org/).

Download the sources off the Specs repository and type

```
$ mvn install
```

Building the Web Console

The web console is composed of several elements and "pre-deployed" in the binary image. Hence it is a little more complicated to build:

First, the web console is composed of 4 parts:

applications/console-core - This component contains common parts shared across the console
applications/console-framework - This component includes the Pluto portal configuration embedded within the console application that hosts the console content.
applications/console-standard - This component contains all of the console "content" delivered as portlets.
applications/console-ear - This component is resopnsible to build the console application that includes all of the above.

When changing any modules in these components you should follow the build order listed above. For example, if you change a module in console-core then you should rebuild console-core, followed by console-framework, followed by console-standard, followed by console-ear. If you only change something in console-standard then you should be ok only building console-standard and console-ear. Maven can be run from each of these "root" locations.

Finally, since the console is a pre-deployed application you should rebuild modules/assembly if you want to update the binary image directly. Otherwise, you can treat the console as any other application and redeploy or undeploy/deploy it manually.

Note: I've noticed some problems at times where modified classes or wars are not picked up in higher level builds (building wars, jars, or ears). To be on the safe side I often find myself preceeding every "maven" with a "maven clean".

Compile Only

Try maven java:compile test:compile or some variation thereof.

Cleaning your workspace

To clean your workspace, type maven clean.

Testing the Build

Start the server:

$ java -jar target/geronimo-1.0/bin/server.jar

Connect to the default root application:

http://localhost:8080/

To stop the server use ctrl-C or an equivalent; a proper shutdown command will be made available when the deployment includes the remoting framework.

You can also start the server using "maven run:server" or "maven debug:server", but startup using maven disables the ctrl-C proper shutdown.

Diagnosing a Failed Test

The following are some quick tips. For further information on unit tests, refer to the Maven Test Plugin and the JUnit documentation

Refer to the test log file (usually has a .log file extension) in the test-reports directory of the module that contains the failing test for events that occured during the execution of tests.
Refer to the the log file for the individual test that failed. The file name has the format TEST-}}testclassname{{.txt

Try running the failing test in isolation. For example:

maven -o -Dtestcase=org.apache.geronimo.FooBarTest test:single

Ascertain whether the test is forked by JUnit (executed in a different process to JUnit). For example, if a geronimo connector test failed, then see whether the maven.junit.fork property is set in the geronimo\modules\connector\project.properties file.
- To debug a test that is not forked by JUnit, set the MAVEN_OPTS environment variable to configure the debugger so that Maven and the JUnit unit test run under the debugger and run the single test as shown above.
  UNIX Korn shell example:
  - export MAVEN_OPTS=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000
    Windows example:
  - set MAVEN_OPTS=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000

To debug a test that is forked by JUnit, you need to configure the debugger via the maven.junit.jvmargs property. For example:

maven -o -Dmaven.junit.jvmargs="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000" -Dtestcase=org.apache.geronimo.FooBarTest test:single

Bypassing Tests

If you don't want to run test at all, try adding -Dmaven.test.skip=true to your maven command line.

If you want to run all the tests but not stop if there's a failure, try adding -Dmaven.test.failure.ignore=true to your maven command line.

Building from behind a firewall / proxy

Windows

If you are behind a corporate network, you may want to use these.

Setting up subversion to tunnel through proxy

In the subversion install folder, you would find a file svn-proxy-template.reg. Edit this file, to include your proxy configuration.

For example, entries can be like

"http-proxy-host"="proxy.us.nw.com"
"http-proxy-port"="8080"
"http-proxy-username"=""
"http-proxy-password"=""

Once you edit and save the file, double click to save and merge these values with windows registry.

If subversion checkout still does not work, try https instead of http. Ie, use

svn checkout https://svn.apache.org/repos/asf/geronimo/trunk geronimo

Setting up maven to tunnel through proxy

In your root geronimo folder after checkout, create a file called build.properties (if it is not already there). Create entries for proxy configuration

For example,

maven.proxy.host=proxy.us.nw.com
maven.proxy.port=8080
#maven.proxy.username=""
#maven.proxy.password=""
#maven.proxy.ntlm.host=""
#maven.proxy.ntlm.domain=""

Save the file, and you are all set. Note: Don't use double quotes around the proxy port - maven doesnt parse it.

Problems?

If having problems building Geronimo, make sure it isn't simply because your Maven repository has become 'corrupted' or out of sync. Delete (or temporarily rename) the .maven directory in your home directory (~ - the tilde - on Unix and %USERPROFILE% on MS Windows) and try building Geronimo again. Make sure that you're online because the dependencies need to be downloaded again.

Running the command maven site seems to take up a lot of memory. If you get the java.lang.OutOfMemoryError, try setting MAVEN_OPTS=-Xmx512m and rerun maven.

One of the many reasons that tests fail is because some ports are in use by other programs (for example another copy of Geronimo running on the same machine). Check the log of the test reports for the specific module that failed in the target/test-reports directory and see if it does use a port that is already active. You can use a program called TCPView (http://www.sysinternals.com/ntw2k/source/tcpview.shtml) to determine which ports are in use by which program and if they are conflicting with ListOfPortsUsedDuringTesting.

Maven Build (or Dependency Download) Problems

Dain writes on Fri, 17 Jun 2005 22:43:11 -0700:

If you're having problem downloading the dependencies with maven,
make sure you are using maven version 1.0.2.  Previous version of
maven, including 1.0, have a bug that breaks with our build.
                                                                                              
dain$ maven -v
__  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

and again Dain writes on the user mailing list:

```
We now use a single global repository list which is way easier to  maintain. In maven 1.0 and 1.0.1 there was a bug that caused a  module to not inherit the repo list from the parent project.
```
If you still have problems, it might be due to an own definiton for "maven.repo.remote" in your $
Unknown macro: {user.home}
/build.properties file. Geronimo uses its own properties file (located in the etc directory) setting the remote repo. If you have your own definition in your user directory, this will override Geronimo's setting and the dependencies might not be found anymore. You can either temporarily remove the settings from the properties file in your home directory or add the settings from the Geronimo properties file to your own - concatenating both information.

Tests fail with java.net.BindException : Address already in use: connect on Windows

The test suites of Geronimo and associated projects can open and close a large number of socket connections within a short period of time, causing Windows to exhaust its pool of ephemeral ports (default is port range 1024-5000). When each of these connections is closed, they will remain in TIME_WAIT for a period of time (default of 240 seconds) before the ephemeral port is available. Windows will not reuse a port until it has exhausted its pool of ephemeral ports. Therefore the Geronimo tests can easily utilise all the ports within 240 seconds. You need to set the MaxUserPort to a larger value and reduce the TcpTimedWaitDelay in the registry settings. See the following for further details: http://support.microsoft.com/kb/196271/EN-US/
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/tcp_time-wait_delay.asp This problem has been encountered whilst running the OpenEJB itests suite.

OpenEJB ITests fail with org.omg.CORBA.COMM_FAILURE on Windows

It has been obvserved that on Windows, port 1050 is used by the IIS Admin service and will cause a org.omg.CORBA.COMM_FAILURE: Unable to listen on /0.0.0.0:1050 (java.net.BindException: Address already in use: JVM_Bind) error. One workaround (assuming the IIS isn't needed to be running) is to go to Services list in the Computer Management console and stop the IIS Admin service, change the startup type for the service to manual. You may need to reboot after this.

Remoting Tests Hang

Make sure the host name of your machine (myworkstation.mydomain.com or whatever) is resolvable in DNS. Worst case, add it to the 127.0.0.1 line in /etc/hosts or c:\windows\system32\drivers\etc\hosts If you use a windows system,try upgrading the JDK to the latest version. There are few bugs in older versions of JDK 1.4, which causes the infinite wait while a server is being closed.

Assembly Fails

It has been noticed that the deployment of the org/apache/geronimo/System plan will not succeed during the assembly phase if it is being done with JVM version:

java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)

The error message that will be seen during the build is:

   [java] Deployed org/apache/geronimo/System
   [java] Deployed org/apache/geronimo/System
   [echo] Building server configuration
   [java] org.apache.geronimo.deployment.DeploymentException: Unable to load parents
   [java]      at org.apache.geronimo.deployment.DeploymentContext.<init>(DeploymentContext.java:99)
   [java]      at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:130)
   [java]      at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:98)
   [java]      at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:145)
   [java]      at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:82)
   [java]      at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:231)
   [java]      at org.apache.geronimo.system.main.CommandLine.<init>(CommandLine.java:106)
   [java]      at org.apache.geronimo.system.main.CommandLine.main(CommandLine.java:64)
   [java] Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: No configuration with id: org/apache/geronimo/System
   [java]      at org.apache.geronimo.kernel.config.ConfigurationManagerImpl.load(ConfigurationManagerImpl.java:129)
   [java]      at org.apache.geronimo.kernel.config.ConfigurationManagerImpl.loadRecursive(ConfigurationManagerImpl.java:175)
   [java]      at org.apache.geronimo.deployment.DeploymentContext.<init>(DeploymentContext.java:97)
   [java]      ... 7 more

or...

     [java] 09:45:15,106 INFO  [ConfigurationManagerImpl] Loaded Configuration geronimo.config:name="org/apache/geronimo/J2EEDeployer"
     [java] 09:45:16,952 INFO  [Configuration] Started configuration org/apache/geronimo/J2EEDeployer
     [java] 09:45:17,228 INFO  [SecurityServiceImpl] JACC factory registered
     [java] 09:45:21,385 INFO  [ConfigurationManagerImpl] Loaded Configuration geronimo.config:name="org/apache/geronimo/Server"
     [java] 09:45:21,419 INFO  [ConfigurationManagerImpl] Loaded Configuration geronimo.config:name="org/apache/geronimo/System"
     [java] 09:45:21,556 INFO  [Configuration] Started configuration org/apache/geronimo/System
     [java] 09:45:22,038 INFO  [Configuration] Stopping configuration org/apache/geronimo/J2EEDeployer
     [java] 09:45:22,127 INFO  [Configuration] Stopping configuration org/apache/geronimo/System
     [java] 09:45:22,150 INFO  [Configuration] Stopping configuration org/apache/geronimo/DeployerSystem
     [java] 09:45:22,155 INFO  [Kernel] Starting kernel shutdown
     [java] 09:45:22,160 INFO  [Kernel] Kernel shutdown complete
     [java] Exception in thread "main" java.lang.NoClassDefFoundError: javax/security/auth/login/Configuration
     [java]     at java.lang.ClassLoader.defineClass0(Native Method)
     [java]     at java.lang.ClassLoader.defineClass(ClassLoader.java:537)
     [java]     at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
     [java]     at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
     [java]     at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
     [java]     at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
     [java]     at java.security.AccessController.doPrivileged(Native Method)
     [java]     at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
     [java]     at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
     [java]     at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
     [java]     at org.apache.geronimo.gbean.runtime.GBeanInstance.<init>(GBeanInstance.java:206)
     [java]     at org.apache.geronimo.kernel.Kernel.loadGBean(Kernel.java:318)
     [java]     at org.apache.geronimo.kernel.config.Configuration.<init>(Configuration.java:235)
     [java]     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
     [java]     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
     [java]     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
     [java]     at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
     [java]     at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:806)
     [java]     at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:331)
     [java]     at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:111)
     [java]     at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:477)
     [java]     at org.apache.geronimo.kernel.Kernel.startGBean(Kernel.java:334)
     [java]     at org.apache.geronimo.deployment.DeploymentContext.<init>(DeploymentContext.java:149)
     [java]     at org.apache.geronimo.deployment.DeploymentContext.<init>(DeploymentContext.java:82)
     [java]     at org.apache.geronimo.j2ee.deployment.EARContext.<init>(EARContext.java:59)
     [java]     at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:283)
     [java]     at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(<generated>)
     [java]     at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
     [java]     at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
     [java]     at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
     [java]     at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:710)
     [java]     at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
     [java]     at org.apache.geronimo.kernel.proxy.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
     [java]     at org.apache.geronimo.kernel.proxy.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:92)
     [java]     at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$661d6fa5.buildConfiguration(<generated>)
     [java]     at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:172)
     [java]     at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:85)
     [java]     at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(<generated>)
     [java]     at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
     [java]     at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
     [java]     at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
     [java]     at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:745)
     [java]     at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:299)
     [java]     at org.apache.geronimo.deployment.cli.ServerConnection$KernelWrapper.invoke(ServerConnection.java:270)     [java]     at org.apache.geronimo.deployment.cli.ServerConnection.invokeOfflineDeployer(ServerConnection.java:253)
     [java]     at org.apache.geronimo.deployment.cli.CommandDistribute.executeOffline(CommandDistribute.java:123)
     [java]     at org.apache.geronimo.deployment.cli.CommandDistribute.execute(CommandDistribute.java:118)
     [java]     at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:113)
     [java]     at org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:254)

Assembly Hangs

If your build gets to
- ```
 [echo] Building server configuration
 
```
  ... and hangs, make sure that you're not running another copy of Geronimo on the same machine. Having a running Geronimo server will interfere with the build process. To prevent this you can use -Dgeronimo.assemble.offline=true but it will take longer and not check that the runtime deployer works.

Assembly fails on Windows due to a forked process from a previous failed assembly attempt not being terminated

If this occurs you will need to terminate the java.exe process manually from the process explorer and retry the assembly.

This may be related to the Ant buzilla issue http://issues.apache.org/bugzilla/show_bug.cgi?id=8510 that suggests it could be a JVM problem?

jar:jar:
assemble:
    [echo] Deleting target directory
    [delete] Deleting directory C:\Projects\J2EE\geronimo\modules\assembly\target

BUILD FAILED
File...... C:\Projects\J2EE\geronimo\modules\assembly\maven.xml
Element... delete
Line...... 76
Column.... 46
Unable to delete file C:\Projects\J2EE\geronimo\modules\assembly\target\geronimo-1.0-SNAPSHOT\bin\server.jar
Total time: 6 seconds

Unable to obtain goal default – <home.dir>\.maven\cache\xmlbeans-maven-plugin-2.0.0-beta1\plugin.jelly:24:23:

This is usually caused by having an old xmlbeans-maven-plugin-2.0.0-beta1 from Geronimo installed in your .maven/cache and $MAVEN_HOME/plugins directories. Unfortunately, it wasn't realized that groupId would be ignored in comparing plugin versions when the version number for the xmlbeans version of this plugin was suggested. It seems that deleting the .maven/cache contents and removing the xmlbeans-maven-plugin-2.0.0-beta1.jar from $MAVEN_HOME/plugins solves the issue - the the correct version and build of the plugin will be downloaded provided you're online.

Improved Maven IDEA plugin

If you use Intellij IDEA, you might like to try this patched version of the maven-idea-plugin. It contains the changes from MPIDEA-13 plus a couple of enhancements from other maven idea plugin patches. When I get a little time I'll update the maven jira issue. maven-idea-plugin-1.5.jar

Creating Intellij IDEA projects

maven -o idea:multiproject

Note: It seems that you need to perform a maven -o m:build before this will properly create all the required modules.