I have an interesting problem with a spring webapp maven build. When being built inside eclipse everything is fine yet when built via maven and deployed to a tomcat 8 container the webapp fails on startup with the following error:
Caused by: java.lang.NoClassDefFoundError: FilterConfig
Now I tried all the obvious and well documented dependency issues (setting scope provided on the javax.servlet-api & jsp-api import and making sure they are of the latest versions as this is a Java 8 project). I have made sure all of the complier plugins are of the latest versions:
maven-war-plugin
3.1.0
maven-compiler-plugin
3.6.1
yet the webapp fails to start with no errors being shown in the maven build console output. After much head-scratching and painstaking comparison between the (working) eclipse build and the mysteriously failing maven equivalent it was discovered that inside some of the class files generated by maven were texts describing compilation problems. (The following was extracted from the "Open With > Text Editor" option in eclipse against the .class file - some of the characters had to be omitted as they wouldn't copy correctly)
Unresolved compilation problems:
The import javax.servlet.Filter cannot be resolved
The import javax.servlet.FilterChain cannot be resolved
The import javax.servlet.FilterConfig cannot be resolved
The import javax.servlet.ServletException cannot be resolved
The import javax.servlet.ServletRequest cannot be resolved
The import javax.servlet.ServletResponse cannot be resolved
The import javax.servlet.http.HttpServletRequest cannot be resolved
The import javax.servlet.http.HttpSession cannot be resolved
Filter cannot be resolved to a type
FilterConfig cannot be resolved to a type
ServletException cannot be resolved to a type
ServletRequest cannot be resolved to a type
ServletResponse cannot be resolved to a type
FilterChain cannot be resolved to a type
ServletException cannot be resolved to a type
HttpServletRequest cannot be resolved to a type
HttpServletRequest cannot be resolved to a type
HttpSession cannot be resolved to a type
I cannot understand how the maven process appears to complete successfully and that no errors are shown with any of the mvn goals I've tried
mvn complier:compile
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building xxxx 2.0.1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) # EBPP ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 5 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.6.1:compile (default-compile) # EBPP ---
[INFO] Nothing to compile - all classes are up to date
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.413 s
[INFO] Finished at: 2017-06-28T15:11:45+01:00
[INFO] Final Memory: 9M/213M
[INFO] ------------------------------------------------------------------------
the above but with the -x showed a lot of debugging output but nothing to suggest compile problems, in fact it states that the class-file identified unresolved dependencies are included
...
[DEBUG] javax.servlet:javax.servlet-api:jar:3.1.0:provided
[DEBUG] org.apache.velocity:velocity:jar:1.7:compile
[DEBUG] commons-collections:commons-collections:jar:3.2.1:compile
[DEBUG] commons-lang:commons-lang:jar:2.4:compile
[DEBUG] javax.servlet.jsp:jsp-api:jar:2.2:provided
...
mvn dependency:build-classpath
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building xxxx 2.0.1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:build-classpath (default-cli) # EBPP ---
[INFO] Dependencies classpath:
C:\Users\xxxxxx\.m2\repository\org\springframework\webflow\spring-webflow\2.4.5.RELEASE\spring-webflow-2.4.5.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\commons-logging\commons-logging\1.2\commons-logging-1.2.jar;C:\Users\xxxxxx\.m2\repository\opensymphony\ognl\2.6.11\ognl-2.6.11.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\webflow\spring-binding\2.4.5.RELEASE\spring-binding-2.4.5.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\webflow\spring-js\2.4.5.RELEASE\spring-js-2.4.5.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\webflow\spring-js-resources\2.4.5.RELEASE\spring-js-resources-2.4.5.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\spring-beans\4.3.0.RELEASE\spring-beans-4.3.0.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\spring-context\4.3.0.RELEASE\spring-context-4.3.0.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\spring-aop\4.3.0.RELEASE\spring-aop-4.3.0.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\spring-expression\4.3.0.RELEASE\spring-expression-4.3.0.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\spring-web\4.3.0.RELEASE\spring-web-4.3.0.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\spring-webmvc\4.3.0.RELEASE\spring-webmvc-4.3.0.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\spring-core\4.3.9.RELEASE\spring-core-4.3.9.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\com\xxxxxxx\ebpp\JComms\2.0.1\JComms-2.0.1.jar;C:\Users\xxxxxx\.m2\repository\log4j\log4j\1.2.17\log4j-1.2.17.jar;C:\Users\xxxxxx\.m2\repository\javax\mail\mail\1.4.7\mail-1.4.7.jar;C:\Users\xxxxxx\.m2\repository\javax\activation\activation\1.1\activation-1.1.jar;C:\Users\xxxxxx\.m2\repository\org\apache\httpcomponents\httpclient\4.5.1\httpclient-4.5.1.jar;C:\Users\xxxxxx\.m2\repository\org\apache\httpcomponents\httpcore\4.4.3\httpcore-4.4.3.jar;C:\Users\xxxxxx\.m2\repository\commons-codec\commons-codec\1.9\commons-codec-1.9.jar;C:\Users\xxxxxx\.m2\repository\commons-httpclient\commons-httpclient\3.1\commons-httpclient-3.1.jar;C:\Users\xxxxxx\.m2\repository\com\xxxxxxx\ebpp\JCore\2.0.1\JCore-2.0.1.jar;C:\Users\xxxxxx\.m2\repository\javax\servlet\javax.servlet-api\3.1.0\javax.servlet-api-3.1.0.jar;C:\Users\xxxxxx\.m2\repository\org\apache\velocity\velocity\1.7\velocity-1.7.jar;C:\Users\xxxxxx\.m2\repository\commons-collections\commons-collections\3.2.1\commons-collections-3.2.1.jar;C:\Users\xxxxxx\.m2\repository\commons-lang\commons-lang\2.4\commons-lang-2.4.jar;C:\Users\xxxxxx\.m2\repository\javax\servlet\jsp\jsp-api\2.2\jsp-api-2.2.jar;C:\Users\xxxxxx\.m2\repository\junit\junit\3.8.2\junit-3.8.2.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\spring-context-support\4.3.9.RELEASE\spring-context-support-4.3.9.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\com\xxxxxxx\xxxxxxx\440\xxxxxxx-440.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.331 s
[INFO] Finished at: 2017-06-28T15:13:05+01:00
[INFO] Final Memory: 13M/213M
[INFO] ------------------------------------------------------------------------
mvn validate
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building xxx 2.0.1
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.109 s
[INFO] Finished at: 2017-06-28T15:15:32+01:00
[INFO] Final Memory: 7M/213M
[INFO] ------------------------------------------------------------------------
I really am stumped. I'm presuming maven is using a different compiler from eclipse but I really have run out of ideas.
Has anyone else encountered this before?
Thanks in advance.
I suspect it's a combination of eclipse building your files with compilation errors (yes, Eclipse can do that: if you never reach the un-compilable code, then you don't even get errors) and Maven not cleaning the output of Eclipse first.
Then Maven sees that the file is up-to-date, and doesn't overwrite it.
I suggest the following (to check if I'm right):
Turn off Eclipse's automatic build (or stop eclipse altogether).
Run a Maven target, such as package but also run clean (i.e. mvn clean package); the point is to be 100% sure that Maven builds those files and not Eclipse.
Maven should now report compilation errors.
As for the error itself, it looks like you are indeed missing a dependency (but probably in Eclipse's classpath, not Maven's).
So when comparing this project to another successful project (that were both converted from Java 4), on the hunch that using non standard directory names was the cause for mavens erratic behavior (while copying the warSourceDirectory). I analysed the (now called) WebRoot > WEB-INF > classes directory and discovered that for the problematic app this had been populated, with you've guessed it - incorrectly compiled class files! Clearly the war plugin copied these bad files over the top of the files Maven had, in the same build process just successfully complied - hence no error.
I am unsure why the bad files were there as they were not in the old Java 4 project. I suspect that they must have been created somehow during a previous failed maven build using incorrect settings.
I am a little confused about the option "includeParents" of the dependency:list goal of the Maven dependency plugin
http://maven.apache.org/plugins/maven-dependency-plugin/list-mojo.html
It seems to me that the parent of the pom itself are not included into the list (I mean the parent of the project pom to which we apply the goal). Is this really the case or did I make some mistake? If so, is there a way to get the parent pom of the project as well?
EXAMPLE:
I used the pom of org.sonatype.plugins:sisu-maven-plugin:1.4 from MavenCentral. It contains a reference to the parent
<parent>
<groupId>org.sonatype.plugins</groupId>
<artifactId>plugins-parent</artifactId>
<version>9</version>
</parent>
But the result of mvn dependency:list -DincludeParents=true is:
javax.inject:javax.inject:jar:1:compile
org.apache.maven:maven-artifact-manager:jar:2.0.8:compile
javax.annotation:jsr250-api:jar:1.0:compile
com.google.code.findbugs:jsr305:jar:1.3.9:compile
org.eclipse.sisu:org.eclipse.sisu.inject:jar:0.2.0:compile
org.apache.maven:maven-model:jar:2.0.8:compile
org.apache.maven:maven-plugin-registry:jar:2.0.8:compile
org.sonatype.sisu:sisu-guice:jar:no_aop:3.1.6:compile
org.apache.maven:maven-project:jar:2.0.8:compile
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-44:compile
org.apache.maven:maven-settings:jar:2.0.8:compile
aspectj:aspectjrt:jar:1.5.3:compile
junit:junit:jar:4.8.2:test
org.apache.maven:maven-repository-metadata:jar:2.0.8:compile
org.sonatype.sisu:sisu-inject-bean:jar:2.5.3:compile
com.google.guava:guava:jar:11.0.2:compile
org.apache.maven.shared:maven-common-artifact-filters:jar:1.4:compile
org.apache.maven.wagon:wagon-provider-api:jar:1.0-beta-2:compile
org.apache.maven:maven-artifact:jar:2.0.8:compile
org.codehaus.plexus:plexus-utils:jar:3.0.15:compile
javax.enterprise:cdi-api:jar:1.0:compile
org.apache.maven:maven-plugin-api:jar:2.0:compile
org.apache.maven:maven-profile:jar:2.0.8:compile
org.codehaus.plexus:plexus-classworlds:jar:1.2-alpha-10:compile
The parameter includeParents was introduced in version 2.8 of the Maven Dependency Plugin:
Include parent poms in the dependency resolution list.
[...]
Since: 2.8
However, the specific Maven project on which you're launching this command declares version 2.2 of the plugin. Here's how I tracked this: sisu-maven-plugin-1.4 has as parent org.sonatype.plugins:plugins-parent:9, which itself has as parent org.sonatype.forge:forge-parent:12, which finally declares version 2.2 of the plugin... Maven will prefer to use that version since it is directly declared in the POM of the project.
Note that you can spot this in the logs as well. When running the command on this project, the logs are:
[INFO] Building Sisu Maven Plugin 1.4
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.2:list (default-cli) # sisu-maven-plugin ---
[INFO]
showing that version 2.2 is the one used.
As such, you just need to force the usage of a version greater than 2.8 for the includeParents parameter to take effect, for example using 2.10 which is the current latest:
mvn org.apache.maven.plugins:maven-dependency-plugin:2.10:list -DincludeParents
I was doing some testing using Maven and realized that I can execute the findbugs goal of the Findbugs plugin without adding the plugin to the POM file. On the other hand, when I needed to run the run goal of the Jetty plugin, I was forced to add the plugin to the POM file or the build failed.
Why Jetty needed configuration in the POM while Findbugs didn't?
How does Maven know which Findbugs to execute (suppose we have to plugins with the same name but different group id)?
When I run the first command the build is successful without any changes in POM file:
mvn findbugs:findbugs
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building module-mytest 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- findbugs-maven-plugin:3.0.4:findbugs (default-cli) # module-mytest ---
[INFO] Fork Value is true
[java] Warnings generated: 6
[INFO] Done FindBugs Analysis....
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 24.165s
[INFO] Finished at: Sun Oct 23 18:40:26 WEST 2016
[INFO] Final Memory: 21M/111M
[INFO] -----------------------------------------------------------------------
But when I run the second I get this:
mvn jetty:run
[INFO] Scanning for projects...
Downloading: http://repo.maven.apache.org/maven2/org/codehaus/mojo/maven-metadata.xml
Downloading: http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-metadata.xml
Downloaded: http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-metadata.xml (13 KB at 30.0 KB/sec)
Downloaded: http://repo.maven.apache.org/maven2/org/codehaus/mojo/maven-metadata.xml (20 KB at 41.0 KB/sec)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.129s
[INFO] Finished at: Sun Oct 23 18:43:27 WEST 2016
[INFO] Final Memory: 12M/104M
[INFO] ------------------------------------------------------------------------
[ERROR] No plugin found for prefix 'jetty' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/home/hp-pc/.m2/repository), central (http://repo.maven.apache.org/maven2)] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/NoPluginFoundForPrefixException
So in order to pass the build I needed to add the following to the pom file:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.2.11.v20150529</version>
</plugin>
What is a prefix and why do we need it?
You just encountered the Plugin Prefix Resolution of Maven. This is a feature which enables the user to invoke goals of a specific Maven plugin, by using its prefix. When you invoke directly a goal on the command-line, you could use the fully-featured form of:
mvn my.plugin.groupId:foo-maven-plugin:1.0.0:bar
This would invoke the goal bar of the Foo Maven plugin having the coordinates my.plugin.groupId:foo-maven-plugin:1.0.0 (in the form of groupId:artifactId:version). It works well, but it is a bit verbose. It would be nice to invoke this goal in a simpler manner, without specifying all those coordinates. Maven makes this possible by assigning prefixes to plugins, so that you can refer to this prefix instead of the whole coordinates, with:
mvn foo:bar
^^^ ^^^
| |
prefix |
|
goal
How is this prefix determined?
You can define a prefix for each Maven plugin. This corresponds to a simple name used to identify it:
The conventional artifact ID formats to use are:
maven-${prefix}-plugin - for official plugins maintained by the Apache Maven team itself (you must not use this naming pattern for your plugin, see this note for more informations)
${prefix}-maven-plugin - for plugins from other sources
If your plugin's artifactId fits this pattern, Maven will automatically map your plugin to the correct prefix in the metadata stored within your plugin's groupId path on the repository.
Put another way, if your plugin's artifact id is named foo-maven-plugin, Maven will automatically assign it a prefix of foo. If you don't want this default assignment, you can still configure your own with the help of the maven-plugin-plugin and its goalPrefix parameter.
How does Maven map prefixes to plugins?
In the command
mvn foo:bar
Maven must have a way to deduce that foo actually means my.plugin.groupId:foo-maven-plugin. In the settings.xml file, you can add plugin groups, in the form of:
<pluginGroups>
<pluginGroup>org.mortbay.jetty</pluginGroup>
</pluginGroups>
What this does, is telling Maven which group id it is supposed to consider when you're using a prefix in a command. By default, and in addition to the groups specified in the settings, Maven also searches the group ids org.apache.maven.plugins and org.codehaus.mojo. It searches those default ones after the ones you configured in the settings. Therefore, with the configuration above, and a command of mvn foo:bar, Maven will look for a plugin having a prefix of foo inside the group id org.mortbay.jetty, org.apache.maven.plugins and org.codehaus.mojo.
The second step is how that search is actually performed. Maven will download metadata files (or look them into your local repository if they are already downloaded), called maven-metadata.xml, from each remote repositories at those group ids. If we take the example where the only remote repository we have is Maven Central, Maven will first download http://repo1.maven.org/maven2/org/mortbay/jetty/maven-metadata.xml, and look inside this file if we have something mapping foo. Notice how the group id was transformed into a directory structure in the remote repository. The structure of this metadata file is:
<metadata>
<plugins>
<plugin>
<name>Some Awesome Maven Plugin</name>
<prefix>somePrefix</prefix>
<artifactId>some-maven-plugin</artifactId>
</plugin>
</plugins>
</metadata>
If none of the <plugin> section contain a <prefix> that is equal to the one we specified (foo), Maven will continue with the next group id, hitting http://repo1.maven.org/maven2/org/codehaus/mojo/maven-metadata.xml. Again, if none are found, Maven will finally hit http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml (notice the Downloading: logs in your mvn jetty:run command, exactly fetching those last two files). If none are still found, there is nothing Maven can do for you anymore, and it will error:
[ERROR] No plugin found for prefix 'foo' in the current project and in the plugin groups [org.mortbay.jetty, org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (.../.m2/repository), central (http://repo.maven.apache.org/maven2)] -> [Help 1]
This is the error you have here. However, if one match was made during this search, then Maven can deduce the <artifactId> to use.
It now means it has the group id, and the artifact id. The final piece of the puzzle is the version
Which version is going to be used?
Maven will take the latest one available, unless explicitly configured in the POM (see next section). All possible versions are retrieved by fetching another metadata file, still called maven-metadata.xml, but this time living alongside the artifact id folder in the repository (contrary to the ones above, where it was alongside the group id). Taking the example of the Maven Clean plugin (whose group id and artifact id would be found with the above mechanism and a command of mvn clean:clean), the maven-metadata.xml looks like:
<metadata>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-clean-plugin</artifactId>
<versioning>
<latest>3.0.0</latest>
<release>3.0.0</release>
<versions>
<version>2.0-beta-1</version>
<version>2.0-rc1</version>
<version>2.0</version>
<version>2.1</version>
<!-- more versions -->
<version>3.0.0</version>
</versions>
<lastUpdated>20151022205339</lastUpdated>
</versioning>
</metadata>
Maven will select as version the <release> version, which represents the latest release version of the plugin. If that tag isn't there, it will select <latest> which represent the latest version of the plugin, release or snapshot. It can happen that both tags are not there, in which case, Maven will select the first release, or the first snapshot for lack of a release, of the list of <version> elements.
If that still fails, there is nothing Maven can do for you anymore, the version couldn't be deduced and it errors. This isn't very likely to happen though. We now have gathered the group id, the artifact id, and the version; time to finally invoke the bar goal of our plugin.
What's the issue with my configuration?
As said above, Maven looks in certain pre-defined group ids inside the active remote repositories to look for matches with a given prefix. With the command
mvn findbugs:findbugs
Maven starts the search with the findbugs prefix. Since our configuration does not have any <pluginGroup> in our settings, Maven looks into org.codehaus.mojo and org.apache.maven.plugins group id for a prefix match.
And it does find one: Findbugs Maven Plugin is published under the org.codehaus.mojo group id; indeed, you can find it in the maven-metadata.xml:
<plugin>
<name>FindBugs Maven Plugin</name>
<prefix>findbugs</prefix>
<artifactId>findbugs-maven-plugin</artifactId>
</plugin>
And you can also find the version that is going to be used by peeking into the maven-metadata.xml file under the findbugs-maven-plugin just deduced (3.0.4 at the time of this writing; and notice how it exactly matches the version in the mvn findbugs:findbugs logs of your question). So the resolution succeeded, and then Maven can continue to invoke the findbugs goal of this plugin.
The second example is the command
mvn jetty:run
As before, the same resolution steps happen, but, in this case, you'll find out that the prefix <jetty> does not appear in any of the maven-metadata.xml for the group ids org.codehaus.mojo and org.apache.maven.plugins. So the resolution fails, and Maven returns the error that you have.
But we've seen how to make it work! We can add a <pluginGroup> inside our settings, so that this group id can also be searched during resolution. The Jetty Maven Plugin is published under the group id org.eclipse.jetty, and if we peek into the corresponding maven-metadata.xml in Maven Central, you'll see that <prefix>jetty</prefix> is there. So the fix is simple: just define this new group id to search inside the settings:
<pluginGroups>
<pluginGroup>org.eclipse.jetty</pluginGroup>
</pluginGroups>
Now, Maven will also look into this group id, and match the jetty prefix to the org.eclipse.jetty:jetty-maven-plugin successfully.
How can I use a specific version? Or, I don't want to modify my settings!
Of course, all of this resolution can be side-tracked if you define the plugin explicitly in your POM, which is the other solution you found:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.2.11.v20150529</version>
</plugin>
and use
mvn jetty:run
If you configure the plugin directly in the POM, the prefix resolution still happens, but it is a bit masked: Maven will download the plugin from the configured remote repositories, and will download and install all metadata files along the way, including the maven-metadata.xml containing the mapping for the prefix jetty. So since it downloads it automatically, the search always succeeds.
Note also that since the plugin was defined in the POM, you wouldn't need any <pluginGroup> in the settings: the group id was written in the POM. Furthermore, it makes sure that the version 9.2.11.v20150529 is going to be used, instead of the latest.
I have a Grails application that uses Maven to build. I wanted to use upgraded version of Grails (from 2.1.0 to 2.3.7). So I just changed version in pom.xml and ran mvn clean install. clean doesn't seem to be running as expected.
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7.472s
[INFO] Finished at: Wed Apr 16 17:32:01 CEST 2014
[INFO] Final Memory: 15M/223M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.grails:grails-maven-plugin:2.3.7:clean
(default-clean) on project search-web-app: Execution default-clean of goal
org.grails:grails-maven-plugin:2.3.7:clean failed: A required class was
missing while executing org.grails:grails-maven-plugin:2.3.7:clean:
groovy/lang/GroovyObject
So it looks the project won't clean because there is no class groovy.lang.GroovyObject.
I tried also version 2.3.6 and 2.3.5, the result is the same. I expect upgrades to plugins included in pom.xml will be also needed, but I think the error would to look different then. Is there someting I can do about it? I tried removing .m2 and .grails caches also, but it didn't help.
have u tried ..> refresh dependencies and then issue grails clean on command line ...some time deleting the bogus file under ./m2 and refresh dependencies might save a lot of time...
also : related to grails maven-clean -U command check this one
grails maven help
mavenRepo ("http://my.server/repos/my-grails-plugins") {
updatePolicy 'always'
}
Here are the possible values for updatePolicy:
never – Never check for new snapshots
always – Always check for new snapshots
daily – Check once a day for new snapshots (the default)
interval:x – Check once every x minutes for new snapshots
#dude back up those cache folder and run mvn clean or grails referesh dependency ...at least you can remove plugin folder or plugins inside that folder by name
To make it work I had to add dependency to Groovy itself:
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>2.2.2</version>
<type>pom</type>
</dependency>
The project now cleans (still does not compile, but I think it's some other issue now).
It was not needed for the previous version of grails plugin.
I also added:
grails.project.dependency.resolver = "maven"
in BuildConfig.groovy.
I am trying to execute the maven-jaxb2-plugin-sample-episode-0.7.4 (explained here and with a download available) to try separate schema compilation. Despite it compiles the first schema (A), it fails in the second one (B) because it is not able to resolve the artifact maven-jaxb2-plugin-sample-episode-a-maven:jar:0.7.4.
I execute mvn assembly:assembly from the command line (windows) and this is the error I get:
...
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven JAXB 2.x Plugin Sample [episode-b|maven]
[INFO] ------------------------------------------------------------------------
[INFO] [jaxb2:generate {execution: default}]
Downloading: http://repo1.maven.org/maven2/org/jvnet/jaxb2/maven2/maven-jaxb2-pl
ugin-sample-episode-a-maven/0.7.4/maven-jaxb2-plugin-sample-episode-a-maven-0.7.
4.jar
[INFO] Unable to find resource 'org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-sample
-episode-a-maven:jar:0.7.4' in repository central (http://repo1.maven.org/maven2
)
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Could not resolve the artifact.
Embedded error: Missing:
----------
1) org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-sample-episode-a-maven:jar:0.7.4
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.jvnet.jaxb2.maven2 -DartifactId=mav
en-jaxb2-plugin-sample-episode-a-maven -Dversion=0.7.4 -Dpackaging=jar -Dfile=/p
ath/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.jvnet.jaxb2.maven2 -DartifactId=maven
-jaxb2-plugin-sample-episode-a-maven -Dversion=0.7.4 -Dpackaging=jar -Dfile=/pat
h/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-ample-episode-b-maven:jar:0
.7.4
2) org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-sample-episode-a-maven:jar:
0.7.4
----------
1 required artifact is missing.
for artifact:
org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-ample-episode-b-maven:jar:0.7.4
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8 seconds
[INFO] Finished at: Wed Dec 22 16:31:29 CET 2010
[INFO] Final Memory: 16M/39M
[INFO] ------------------------------------------------------------------------
The example should work as it is so, what am I doing wrong ? In the real scenario I have more than 10 schemas that have to be compiled as different episodes, so I need the proccess to be automatic (i.e no need to execute "mvn something" for each individual artifact)
The module maven-jaxb2-plugin-ample-episode-b-maven depends on maven-jaxb2-plugin-ample-episode-a-maven.
When mvn assembly:assembly is run from the parent folder (which contains the two modules), it builds the jar for maven-jaxb2-plugin-ample-episode-a-maven, but does not install it in your local repository.
When it then tries to build maven-jaxb2-plugin-ample-episode-b-maven, it looks for the dependency (maven-jaxb2-plugin-ample-episode-a-maven) and fails to find it in the local repository. Thus the error.
The question is, why would you want to run mvn assembly:assembly, which is used to create a binary distribution? There are no assembly descriptors in either module.
mvn install works fine and build both the modules successfully.