I was converting one of our projects over from ant to maven when I got this confusing error;

MethodParameters.java:[4,20] package org.jmock.api does not exist

I checked and re-checked the dependencies in the pom and couldn't work out why it wouldn't compile. In the end I had the light bulb and realized I had restricted the scope of jmock to test. The MethodParameters class is a utility tool to help testing and had to be compiled. It wasn't purely for the purposes of running unit tests.

I am slowly moving over all our projects to maven. I have a remote repository set up on our network with nexus and already another project is hooked into it and using it for third party dependencies.

I set up an install of nexus so we can have local repository. With all the third party stuff such as the sun libraries for jms etc we need a third party repository. Added benefit is that we will start using the snapshot and release repositories as well.

The documentation in the O'Reilly Maven book and on the vimeo video for how to set up and start nexus were bit old. It took me a while to work out how to upload third party artifacts to the repository. As it turns out, you have to be logged in, and when you click on the third party repository then one of the tabs that will display in the bottom window is Artifact Upload.

I got this error when building an ear file that contained a MANIFEST.MF with a buildNumber that was generated by the buildnumber maven plugin;

java.lang.NullPointerException: The scm url cannot be null.
at org.apache.maven.scm.manager.AbstractScmManager.makeScmRepository(AbstractScmManager.java:181)
at org.codehaus.mojo.build.CreateMojo.getScmRepository(CreateMojo.java:722)
at org.codehaus.mojo.build.CreateMojo.getRevision(CreateMojo.java:644)
at org.codehaus.mojo.build.CreateMojo.execute(CreateMojo.java:431)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

Apparently it requires the scm tag be filled in as part of the pom. The confusing part is that despite it saying the URL cannot be null, it is actually the developerConnection tag being absent that causes it. The reason is that the buildNumber plugin needs to know where the repository is so that it can pull the Subversion revision number. The developerConnection tag is a bit confusing as well. I ended up with the format;

scm:svn:svn://localhost/projects/myProject/trunk

The three codes between the :'s mean, it is for scm, it is for subversion, and then the subversion url of which svn:// is the start. Confusing.

We use WLDeploy as an ant task to hot deploy our ears into weblogic via an ant script. I am moving that over to maven. I had the dependency for weblogic.jar but got the error;

[INFO] ---------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ---------------------------------------------------
[INFO] An Ant BuildException has occured: java.lang.NoClassDefFoundError: weblogic/utils/Debug
 weblogic.utils.Debug

I needed to add the wlfullclient.jar as a dependency and then add it to the classpathref for the ant target inside the pom.

Following on from this issue; next bump in using WLDeploy;

 Error J2EE Deployment SPI BEA-260125 Errors detected attempting to communicate with admin server: [J2EE Deployment SPI:260111]
Errors detected attempting to communicate with admin server.
weblogic.deploy.api.spi.exceptions.ServerConnectionException: [J2EE Deployment SPI:260111]Errors detected attempting to communicate with admin server.
at weblogic.deploy.api.spi.deploy.mbeans.MBeanCache.getMBeans(MBeanCache.java:65)
at weblogic.deploy.api.spi.deploy.mbeans.ModuleCache.getModules(ModuleCache.java:85)
at weblogic.deploy.api.spi.deploy.mbeans.ModuleCache.getResultTmids(ModuleCache.java:305)
at weblogic.deploy.api.spi.status.ProgressObjectImpl.updateTmids(ProgressObjectImpl.java:181)
at weblogic.deploy.api.spi.status.ProgressObjectImpl.getResultTargetModuleIDs(ProgressObjectImpl.java:158)
at weblogic.deploy.api.spi.status.ProgressObjectImpl.reportEvent(ProgressObjectImpl.java:334)
at weblogic.deploy.api.spi.deploy.internal.ServerConnectionImpl$TaskPoller.poll(ServerConnectionImpl.java:1067)
at weblogic.deploy.api.spi.deploy.internal.ServerConnectionImpl$TaskPoller.run(ServerConnectionImpl.java:1032)
java.lang.NoClassDefFoundError: weblogic/j2ee/descriptor/wl/DeploymentPlanBean
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.privateGetPublicMethods(Class.java:2547)
at java.lang.Class.getMethods(Class.java:1410)
at sun.misc.ProxyGenerator.generateClassFile(ProxyGenerator.java:409)
at sun.misc.ProxyGenerator.generateProxyClass(ProxyGenerator.java:306)
at java.lang.reflect.Proxy.getProxyClass(Proxy.java:501)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:581)
at weblogic.management.jmx.MBeanServerInvocationHandler.newProxyInstance(MBeanServerInvocationHandler.java:264)
at weblogic.management.jmx.MBeanServerInvocationHandler.newProxyInstance(MBeanServerInvocationHandler.java:636)
at weblogic.management.jmx.MBeanServerInvocationHandler.newProxyInstance(MBeanServerInvocationHandler.java:200)
at weblogic.management.jmx.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:431)
at $Proxy6.getAppDeployments(Unknown Source)
at weblogic.deploy.api.spi.deploy.mbeans.ModuleCache.getTypedMBeans(ModuleCache.java:55)
at weblogic.deploy.api.spi.deploy.mbeans.MBeanCache.getMBeans(MBeanCache.java:56)
at weblogic.deploy.api.spi.deploy.mbeans.ModuleCache.getModules(ModuleCache.java:85)
at weblogic.deploy.api.spi.deploy.mbeans.ModuleCache.getResultTmids(ModuleCache.java:305)
at weblogic.deploy.api.spi.status.ProgressObjectImpl.updateTmids(ProgressObjectImpl.java:181)
at weblogic.deploy.api.spi.status.ProgressObjectImpl.getResultTargetModuleIDs(ProgressObjectImpl.java:158)
at weblogic.deploy.api.spi.status.ProgressObjectImpl.reportEvent(ProgressObjectImpl.java:334)
at weblogic.deploy.api.spi.deploy.internal.ServerConnectionImpl$TaskPoller.poll(ServerConnectionImpl.java:1067)
at weblogic.deploy.api.spi.deploy.internal.ServerConnectionImpl$TaskPoller.run(ServerConnectionImpl.java:1032)
java.lang.ClassNotFoundException: weblogic.j2ee.descriptor.wl.DeploymentPlanBean
at org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1361)
at org.apache.tools.ant.AntClassLoader.findClass(AntClassLoader.java:1311)
at org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:1064)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.privateGetPublicMethods(Class.java:2547)
at java.lang.Class.getMethods(Class.java:1410)
at sun.misc.ProxyGenerator.generateClassFile(ProxyGenerator.java:409)
at sun.misc.ProxyGenerator.generateProxyClass(ProxyGenerator.java:306)
at java.lang.reflect.Proxy.getProxyClass(Proxy.java:501)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:581)
at weblogic.management.jmx.MBeanServerInvocationHandler.newProxyInstance(MBeanServerInvocationHandler.java:264)
at weblogic.management.jmx.MBeanServerInvocationHandler.newProxyInstance(MBeanServerInvocationHandler.java:636)
at weblogic.management.jmx.MBeanServerInvocationHandler.newProxyInstance(MBeanServerInvocationHandler.java:200)
at weblogic.management.jmx.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:431)
at $Proxy6.getAppDeployments(Unknown Source)
at weblogic.deploy.api.spi.deploy.mbeans.ModuleCache.getTypedMBeans(ModuleCache.java:55)
at weblogic.deploy.api.spi.deploy.mbeans.MBeanCache.getMBeans(MBeanCache.java:56)
at weblogic.deploy.api.spi.deploy.mbeans.ModuleCache.getModules(ModuleCache.java:85)
at weblogic.deploy.api.spi.deploy.mbeans.ModuleCache.getResultTmids(ModuleCache.java:305)
at weblogic.deploy.api.spi.status.ProgressObjectImpl.updateTmids(ProgressObjectImpl.java:181)
at weblogic.deploy.api.spi.status.ProgressObjectImpl.getResultTargetModuleIDs(ProgressObjectImpl.java:158)
at weblogic.deploy.api.spi.status.ProgressObjectImpl.reportEvent(ProgressObjectImpl.java:334)
at weblogic.deploy.api.spi.deploy.internal.ServerConnectionImpl$TaskPoller.poll(ServerConnectionImpl.java:1067)
at weblogic.deploy.api.spi.deploy.internal.ServerConnectionImpl$TaskPoller.run(ServerConnectionImpl.java:1032)

The solution is to add com.bea.core.desriptor.wl_1.1.0.0.jar to the classpath for the WLDeploy task. Now the ear is deploying via maven through ant to weblogic.

Trying to mavenize our weblogic webservices layer and tripping over this error with weblogic-maven-plugin;

weblogic.wsee.tools.WsBuildException: JWS Validation failed: [Enum Types are not supported on a JWS: ...]

The issue seems to be that the maven-weblogic-plugin doesn't have the JAXWS type as a configuration field and it is trying to make them all JAX-RPC. That would explain why the Ant target works and the maven one does not.

Update

I modified the weblogoc-maven-plugin to support JAXWS. I had to change a line of code in JwscMojo.java adding;

final JwsFileSet jwsFileSet = module.createJwsFileSet();
jwsFileSet.setType("JAXWS");

Which sets it to JAXWS rather than the default JAX-RPC.

Got a confusing error from maven this morning;

Cannot execute mojo: resources. It requires a project with an existing pom.xml, but the build is not using one.

This means you are in a directory that does not have a pom in it. Doh.

When running the jwsc task from the weblogic-maven-plugin on windows I was getting this error;

[ERROR] Failed to execute goal Lifelock:weblogic-maven-plugin:2.9.1.1-SNAPSHOT:jwsc (generate.weblogic.webservices) on project ... Exception encountered during jwsc: Failed to copy C:\Users\bamboo\AppData\Local\Temp\BP-MB\_ytegi8\web.xml to C:\Atlassian\bamboo-home\xml-data\build-dir\BP\ES\target\C:\Atlassian\bamboo-home\xml-data\build-dir\BP\ES\target\classes\WEB-INF\WEB-INF\web.xml due to C:\Atlassian\bamboo-home\xml-data\build-dir\BP\ES\target\C:\Atlassian\bamboo-home\xml-data\build-dir\BP\ES\target\classes\WEB-INF\WEB-INF\web.xml (The filename, directory name, or volume label syntax is incorrect) -> [Help 1]

From that error it appeared that the fullpath was being appended twice. For what it is worth, it works on mac/OSX without an issue. The pom for OSX had the outputName configuration elements as ${project.build.outputDirectory}/WEB-INF. I removed that for windows and the maven lifecycle ran to completion. I guess it is a bug in the oracle or be a ant task that the weblogic-maven-plugin wraps. I couldn't find the bug in the plugin itself.

Quite annoying as I had it running on my mac pro before I checked it in. But our bamboo server is on Windows 7. So it failed as soon as the script was put into continuous integration.

This rings true; "Since maven is essentially a very, very high-level abstraction, you are the mercy of the plugin developers as to what you can do. For example, it is not possible to run your integration tests through Cobertura. The plugin developers didn't provide this and there's no way to do it without some major hacking of your test code organization and pom file. This is bending your process to fit a tool's shortcoming. This is limitation designed into maven."

Fortunately the plugin that was causing us issues was the weblogic plugin and it was opensourced, so I was able to modify it and then push it up to our local nexus repository. That being said I couldn't find the latest versions and ended up modifying an older publicly available version.

Java's classpath means it isn't in a system level language. When you install python eggs, perl libraries or C# dll's they are installed at the operating system level. Python has virtualenv now which acts like a classpath, but when you decided to use install something that was kind of it for python.

I can remember mucking around with easy_install to try and find a balance with SQLObject so I could downgrade it so my stuff would work, but not downgrade it so much that it would break other python eggs that relied on it.

Maven grew out of managing all the classpath level dependencies in a java project. I don't recall the original maven doing all the SCM stuff. It basically just pulled down all the jar versions of different (apache) projects into your project's classpath.

I ported the last of our ears to maven today. We use jaxws to build the classes for our webservices using the maven weblogic plugin. We had to modify that plugin several times for JAXWS and to build it on windows.

Our bamboo server and nexus repository are both running on a windows machine which caused some issues as most of the maven porting from ant was done on OSX boxes. There was some incompatibilities there that had to be solved once the plans were run on Bamboo/Windows rather than bash/osx.

The maven builds all to a clean build, testing and then deployment on each check in. We have yet to hook in the integration phase with our functional tests but once we do we are essentially doing continuous deployment in the dev/qa environment. Once we hammer that out I would like to see it move up to stage and eventually production.

I am still not a fan of Bamboo. I think Hudson would be a better continuous integration server for our purposes. Unfortunately, we are not the only users of it and other groups use the integrated Atlassian bundle of Bamboo, Jira, Crucible, Greenhopper, etc. I think Confluence is intended to become our wiki environment as well.

We have common libraries and common dto jars etc. We also feature branch now and will have multiple branches up in the air at any one time. That is easier to manage with maven. Because of the environments we have the build plans are split up by environment on bamboo as well. Which is working out well.

When developing the maven poms it can be poke and hope. Especially as compile and runtime can be two different issues with dependencies. I did the poms in the skinny war/ear style. Where the scope is provided on everything except the ear pom. All our ears have a parent pom as well which flows down the version numbers of common libraries into the WS, EJB, Client layers etc.

Maven is an improvement over ant even though you are forced to do it the maven way. Ant certainly has more flexibility but it is worth it for the versioning power out of the box maven brings and the ease of managing dependencies in continuous integration and deployment.