I am making a maven project that will make use of Jaxb2-maven-plugin to generate java files out of xsd files. My Project structure is like:
project.basedir
--src/main/resources/schemas
----common
----request
----response
Below is the plugin config from pom.xml
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxb2-maven-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<id>xjc-PDF</id>
<phase>generate-sources</phase>
<goals>
<goal>xjc</goal>
</goals>
<configuration>
<extension>true</extension>
<clearOutputDir>false</clearOutputDir>
<outputDirectory>${project.build.directory}/generated-sources/jaxb</outputDirectory>
<explicitAnnotation>true</explicitAnnotation>
<!-- <schemaDirectory>${project.basedir}/src/main/resources/schemas</schemaDirectory> -->
<sources>
<source>${project.basedir}/src/main/resources/schemas/common</source>
<source>${project.basedir}/src/main/resources/schemas/response</source>
<source>${project.basedir}/src/main/resources/schemas/request</source>
</sources>
<bindingDirectory>${project.basedir}/src/main/resources/schemas</bindingDirectory>
<!-- <bindingDirectory>${project.basedir}/src/main/resources/bindings</bindingDirectory> -->
<bindingFiles>jaxb-bth.xjb</bindingFiles>
</configuration>
</execution>
</executions>
</plugin>
If I compile like this then I get below error (even though the source directories contains valid schema files):
C:\ESB_SOAP5_Space\pdf-util>mvn clean install
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building pdf-util 1.0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) # pdf-util ---
[INFO] Deleting C:\ESB_SOAP5_Space\pdf-util\target
[INFO]
[INFO] --- build-helper-maven-plugin:1.6:add-source (add-source) # pdf-util ---
[INFO] Source directory: C:\ESB_SOAP5_Space\pdf-util\target\generated-sources\jaxb added.
[INFO]
[INFO] --- jaxb2-maven-plugin:1.6:xjc (xjc-PDF) # pdf-util ---
[INFO] Generating source...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.205 s
[INFO] Finished at: 2018-03-19T06:27:02+11:00
[INFO] Final Memory: 8M/245M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:jaxb2-maven-plugin:1.6:xjc (xjc-PDF) on project pdf-util: No schemas have been found -> [Help 1]
However, if I comment sources and uncomment and modify like below, then I am able to generate java classes out of schemas under common.
<schemaDirectory>${project.basedir}/src/main/resources/schemas/common</schemaDirectory>
Can anyone tell me why is this behaving like this? Also what do I do if I have to parse all the schema files under one root folder ( which has multiple child folders)?
Thanks
Version 1.6 of the plugin does not support "sources" tag. You can use "sources tag on version 2.4 or newer.
If you have multiple directories containing xsds, use multiple executions in your configuration with each schemaDirectory pointing to one of your directories.
Related
I am trying to use spotbugs from maven.
In the <reporting/> section of my POM, I include
<plugin>
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-maven-plugin</artifactId>
<version>4.5.3.0</version>
<configuration>
<includeFilterFile>spotbugs-security-include.xml</includeFilterFile>
<excludeFilterFile>spotbugs-security-exclude.xml</excludeFilterFile>
<plugins>
<plugin>
<groupId>com.h3xstream.findsecbugs</groupId>
<artifactId>findsecbugs-plugin</artifactId>
<version>1.11.0</version>
</plugin>
</plugins>
</configuration>
</plugin>
Where do I put the filter files spotbugs-security-include.xml and spotbugs-security-exclude.xml?
According to the documentation, the plugin will find the filter files on the classpath. But what is the classpath for executing a reporting plugin? And where in the source tree do I put the files in order to have them copied there during report generation? I have tried src/main/resources, src/test/resources, and src/site/resources with no luck.
Log snippet:
[INFO] 6 reports detected for maven-javadoc-plugin:3.2.0: aggregate-no-fork, javadoc, javadoc-no-fork, test-aggregate-no-fork, test-javadoc, test-javadoc-no-fork
[INFO] configuring report plugin com.github.spotbugs:spotbugs-maven-plugin:4.5.3.0
[INFO] 1 report detected for spotbugs-maven-plugin:4.5.3.0: spotbugs
[INFO] configuring report plugin org.apache.maven.plugins:maven-project-info-reports-plugin:3.1.2
[INFO] 15 reports detected for maven-project-info-reports-plugin:3.1.2: ci-management, dependencies, dependency-info, dependency-management, distribution-management, index, issue-management, licenses, mailing-lists, modules, plugin-management, plugins, scm, summary, team
[INFO] Fork Value is true
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 25.587 s
[INFO] Finished at: 2022-02-11T15:31:56+01:00
[INFO] ------------------------------------------------------------------------
[ERROR] Could not find resource 'spotbugs-security-include.xml'. -> [Help 1]
I run under OpenJDK 11 on linux.
Are the pre and post phases always executed when I execute the associated phase? For example, if I do mvn clean, will this execute the mvn post-clean phase, too?
I was looking at https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference, in which it said:
The following lists all build phases of the default, clean and site
lifecycles, which are executed in the order given up to the point of
the one specified.
So strictly speaking, since post-clean comes after clean, it should not be executed if I just do mvn clean. But my gut feel is different - although, I didn't find a way to verify this, as the maven stdout doesn't print the phase it's executing.
Could anyone weigh in on the answer and how you verified?
You can bind a plugin (such as echo-maven-plugin) to the phases of the clean lifecycle to help verify if/when each phase is executed.
For example, given the following plugin definition:
<plugin>
<groupId>com.github.ekryd.echo-maven-plugin</groupId>
<artifactId>echo-maven-plugin</artifactId>
<version>1.2.0</version>
<executions>
<execution>
<id>pre-clean</id>
<phase>pre-clean</phase>
<goals>
<goal>echo</goal>
</goals>
<configuration>
<message>In 'pre-clean'</message>
</configuration>
</execution>
<execution>
<id>clean</id>
<phase>clean</phase>
<goals>
<goal>echo</goal>
</goals>
<configuration>
<message>In 'clean'</message>
</configuration>
</execution>
<execution>
<id>post-clean</id>
<phase>post-clean</phase>
<goals>
<goal>echo</goal>
</goals>
<configuration>
<message>In 'post-clean'</message>
</configuration>
</execution>
</executions>
</plugin>
Invoking mvn clean will result in the following output:
$ mvn clean
[INFO] Scanning for projects...
[INFO]
[INFO] --- echo-maven-plugin:1.2.0:echo (pre-clean) # sandbox ---
[INFO] In 'pre-clean'
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) # sandbox ---
[INFO] Deleting target
[INFO]
[INFO] --- echo-maven-plugin:1.2.0:echo (clean) # sandbox ---
[INFO] In 'clean'
So, there's no invocation of the post-clean phase there.
Invoking mvn clean compile will result in the following output:
$ mvn clean compile
[INFO] Scanning for projects...
[INFO]
[INFO] --- echo-maven-plugin:1.2.0:echo (pre-clean) # sandbox ---
[INFO] In 'pre-clean'
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) # sandbox ---
[INFO]
[INFO] --- echo-maven-plugin:1.2.0:echo (clean) # sandbox ---
[INFO] In 'clean'
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) # sandbox ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO]
[INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile) # sandbox ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 5 source files to ...
Again, there's no invocation of the post-clean phase there. This implies that the maven-clean-plugin (and perhaps nothing else) is not bound to post-clean.
Invoking mvn post-clean will result in the post-clean phase being invoked ...
$ mvn post-clean
[INFO] Scanning for projects...
[INFO]
[INFO] --- echo-maven-plugin:1.2.0:echo (pre-clean) # sandbox ---
[INFO] In 'pre-clean'
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) # sandbox ---
[INFO] Deleting target
[INFO]
[INFO] --- echo-maven-plugin:1.2.0:echo (clean) # sandbox ---
[INFO] In 'clean'
[INFO]
[INFO] --- echo-maven-plugin:1.2.0:echo (post-clean) # sandbox ---
[INFO] In 'post-clean'
So, based on the above test I think the following statements are true:
post-clean is not invoked when you call clean
post-clean is only called when you explicitly invoke post-clean (note: invoking the pre- and post- phases directly is unusual)
I'm attempting to add integration tests to a large Maven project. Here is the desired order of events:
Clean existing artifacts.
Resolve dependencies and build project.
Run unit tests via Surefire plugin.
Fork lifecycle for Clover plugin.
--- Instrument sources using Clover plugin.
--- Modify project.build.directory and project.build.finalName for Clover.
--- Build Clover instrumented project in a new directory.
--- Run Clover instrumented unit tests via Surefire plugin.
--- Check code coverage from Clover instrumented unit tests.
--- Reset project.build.directory and project.build.finalName to original values.
--- End forked lifecycle (Clover only forks through 'test' phase).
Package project as a WAR file.
Locally host project WAR file via Tomcat7 plugin.
Run integration tests against Tomcat7 instance via Surefire plugin.
All of this works as expected except step #9 (hence the question). Instead, the build directory is still set to the Clover version, and the project name has "-clover" appended to it. I've also found that when "MyProject-clover.war" is hosted by Tomcat7 that it does not function as expected (returns a 404 error in the browser).
Even if it did work, We do not need/want Clover instrumentation in the WAR file which we're testing against because the integration tests don't touch any of the production code (it's all Selenium UI stuff under src/test/java which interacts with the locally hosted pages instead of the production code itself).
As mentioned, this is a large project containing hundreds of dependencies and dozens of plugins. I believe the following are relevant to my issue, though I can dig up more if necessary (posting the entire pom file seems unreasonable).
Here's the pom configuration for the Clover plugin:
<plugin>
<groupId>com.atlassian.maven.plugins</groupId>
<artifactId>maven-clover2-plugin</artifactId>
<version>3.1.11</version>
<configuration>
<generateHtml>true</generateHtml>
<generateXml>true</generateXml>
<licenseLocation>${basedir}/src/test/resources/clover.license</licenseLocation>
<targetPercentage>92%</targetPercentage>
<excludes>
<exclude>**/mock/*.java</exclude>
<exclude>**/com/mycompany/somestuff/*.java</exclude>
</excludes>
</configuration>
<executions>
<execution>
<id>generate-clover-report</id>
<phase>test</phase>
<goals>
<goal>instrument</goal>
<goal>clover</goal>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
Here's the pom configuration for the WAR plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<finalName>${project.artifactId}</finalName>
<appendAssemblyId>false</appendAssemblyId>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
</manifest>
<manifestEntries>
<!--Implementation-Build>${buildNumber}_${timestamp}</Implementation-Build -->
<Build-Time>${timestamp}</Build-Time>
</manifestEntries>
</archive>
</configuration>
</plugin>
Here's the pom configuration for the Tomcat7 plugin:
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<ajpPort>8009</ajpPort>
<backgroundProcessorDelay>2</backgroundProcessorDelay>
<configurationDir>${project.build.directory}/tomcat7_plugin</configurationDir>
<contextFile>${CATALINA_HOME}/conf/context.xml</contextFile>
<contextReloadable>false</contextReloadable>
<fork>true</fork>
<hostName>localhost</hostName>
<httpsPort>8443</httpsPort>
<ignorePackaging>false</ignorePackaging>
<jarScanAllDirectories>false</jarScanAllDirectories>
<path>/contentmain</path>
<port>8080</port>
<serverXml>${CATALINA_HOME}/conf/server.xml</serverXml>
<tomcatUsers>${CATALINA_HOME}/conf/tomcat-users.xml</tomcatUsers>
<tomcatWebXml>${CATALINA_HOME}/conf/web.xml</tomcatWebXml>
<useNaming>true</useNaming>
<useTestClasspath>true</useTestClasspath>
<update>true</update>
<warDirectory>${project.build.directory}/${project.build.finalName}</warDirectory>
</configuration>
<executions>
<execution>
<id>start-tomcat</id>
<phase>pre-integration-test</phase>
<goals>
<goal>run-war-only</goal>
</goals>
<configuration>
<fork>true</fork>
</configuration>
</execution>
<execution>
<id>stop-tomcat</id>
<phase>post-integration-test</phase>
<goals>
<goal>shutdown</goal>
</goals>
</execution>
</executions>
</plugin>
Here's the current (desired) behavior when I run "mvn clean install -Dmaven.clover.skip":
[INFO] --- maven-clover2-plugin:3.1.11:check (generate-clover-report) # MyProject ---
[INFO]
[INFO] --- maven-dependency-plugin:2.1:unpack (unpack) # MyProject ---
[INFO] Configured Artifact: com.mycompany:somedependency:?:jar
[INFO] Configured Artifact: com.mycompany:somedependency:?:jar
[INFO] Configured Artifact: com.mycompany:somedependency:?:jar
[INFO] Unpacking /mydir/.m2/myrepo/mycompany/somedir/somedependency.jar to mydir/MyProject/target/MyProject with includes css/*.css and excludes:null
[INFO] Unpacking /mydir/.m2/myrepo/mycompany/somedir/somedependency.jar to mydir/MyProject/target/MyProject with includes scripts/*/*.* and excludes:null
[INFO] Unpacking /mydir/.m2/myrepo/mycompany/somedir/somedependency.jar to mydir/MyProject/target/MyProject with includes images/*.* and excludes:null
[INFO]
[INFO] --- maven-war-plugin:2.1.1:war (default-war) # MyProject ---
[INFO] Packaging webapp
[INFO] Assembling webapp [MyProject] in [mydir/MyProject/target/MyProject]
[INFO] Processing war project
[INFO] Copying webapp resources [mydir/MyProject/src/main/webapp]
[INFO] Webapp assembled in [2019 msecs]
[INFO] Building war: /mydir/MyProject/target/MyProject.war
[INFO] WEB-INF/web.xml already added, skipping
[INFO]
[INFO] >>> maven-source-plugin:2.2.1:jar (default) # MyProject >>>
[INFO]
[INFO] --- maven-dependency-plugin:2.1:copy (default) # MyProject ---
[INFO]
[INFO] --- buildnumber-maven-plugin:1.1:create-timestamp (default) # MyProject ---
[INFO]
[INFO] <<< maven-source-plugin:2.2.1:jar (default) # MyProject <<<
[INFO]
[INFO] --- maven-source-plugin:2.2.1:jar (default) # MyProject ---
[INFO] Building jar: /mydir/MyProject/target/MyProject-sources.jar
[INFO]
[INFO] --- tomcat7-maven-plugin:2.2:run-war-only (start-tomcat) # MyProject ---
[INFO] Running war on http://localhost:8080/contentmain
Here's the current (undesired) behavior when I run "mvn clean install" (note the paths listed by maven-war-plugin and warning message from maven-source-plugin:
[INFO] --- maven-clover2-plugin:3.1.11:check (generate-clover-report) # MyProject ---
[INFO]
[INFO] --- maven-dependency-plugin:2.1:unpack (unpack) # MyProject ---
[INFO] Configured Artifact: com.mycompany:somedependency:?:jar
[INFO] Configured Artifact: com.mycompany:somedependency:?:jar
[INFO] Configured Artifact: com.mycompany:somedependency:?:jar
[INFO] Unpacking /mydir/.m2/myrepo/mycompany/somedir/somedependency.jar to mydir/MyProject/target/MyProject with includes css/*.css and excludes:null
[INFO] Unpacking /mydir/.m2/myrepo/mycompany/somedir/somedependency.jar to mydir/MyProject/target/MyProject with includes scripts/*/*.* and excludes:null
[INFO] Unpacking /mydir/.m2/myrepo/mycompany/somedir/somedependency.jar to mydir/MyProject/target/MyProject with includes images/*.* and excludes:null
[INFO]
[INFO] --- maven-war-plugin:2.1.1:war (default-war) # MyProject ---
[INFO] Packaging webapp
[INFO] Assembling webapp [MyProject] in [mydir/MyProject/target/clover/MyProject-clover]
[INFO] Processing war project
[INFO] Copying webapp resources [mydir/MyProject/src/main/webapp]
[INFO] Webapp assembled in [1770 msecs]
[INFO] Building war: /mydir/MyProject/target/clover/MyProject-clover.war
[INFO] WEB-INF/web.xml already added, skipping
[INFO]
[INFO] >>> maven-source-plugin:2.2.1:jar (default) # MyProject >>>
[INFO]
[INFO] --- maven-dependency-plugin:2.1:copy (default) # MyProject ---
[INFO]
[INFO] --- buildnumber-maven-plugin:1.1:create-timestamp (default) # MyProject ---
[INFO]
[INFO] <<< maven-source-plugin:2.2.1:jar (default) # MyProject <<<
[INFO]
[INFO] --- maven-source-plugin:2.2.1:jar (default) # MyProject ---
[WARNING] NOT adding sources to artifacts with classifier as Maven only supports one classifier per artifact. Current artifact [com.mycompany:MyProject:war:clover:ParentProject-SNAPSHOT] has a [clover] classifier.
[INFO]
[INFO] --- tomcat7-maven-plugin:2.2:run-war-only (start-tomcat) # MyProject ---
[INFO] Running war on http://localhost:8080/contentmain
What can I do to make sure that the {project.build.directory} and {project.build.finalName} values are reset to their original values after Clover has finished executing the maven-clover2-plugin:check goal during the test phase of the forked lifecycle?
I've already tried browsing the online manuals for Clover, the WAR plugin, and Tomcat7. I see no mention of any settings I can use to revert the build variables that are altered by Clover. I can always hard-code the paths in my pom file, but I'd prefer a less brittle solution.
[INFO] --- maven-source-plugin:2.2.1:jar (default) # MyProject ---
[WARNING] NOT adding sources to artifacts with classifier as Maven only supports one classifier per artifact. Current artifact [com.mycompany:MyProject:war:clover:ParentProject-SNAPSHOT] has a [clover] classifier.
This is a limitation of Maven. It does not support artifacts with multiple classifiers. As the artifact in a forked life cycle has the "clover" classifier already, it cannot have "source" classifier at the same time. That's why this warning is present. You may consider using the clover2:setup instead of the clover2:instrument if you need to call a maven-source-plugin.
4. Fork lifecycle for Clover plugin.
--- End forked lifecycle (Clover only forks through 'test' phase).
There are two Clover goals which forks a build:
clover2:instrument - forks a build till the 'install' phase
clover2:instrument-test - forks a build till the 'test' phase
You may be interested in the latter one. You may also be interested in using the useCloverClassifier=false option - this will disable usage of the "clover" classifier in a forked build.
I've also found that when "MyProject-clover.war" is hosted by Tomcat7 that it does not function as expected (returns a 404 error in the browser).
My first guess is that you have clover.jar (com.atlassian.clover:clover) missing at runtime. You have to either copy clover.jar to Tomcat's /lib directory or to bundle it in your WAR. See https://confluence.atlassian.com/display/CLOVER/Using+Clover+for+web+applications
It turns out that Clover will always alter these variables unless the clover2:setup target is used. However, if you still wish to fork the lifecycle for Clover (IE: clover2:instrument or clover2:instrument-test) then these variables will always be altered.
We wish to continue forking the lifecycle using clover:instrument-test, so I've come up with a workaround. Instead of using the project.build.finalName and project.build.directory variables, I'm using my own variables that get copied and saved on Maven execution before Clover can mess with them:
<properties>
<!-- Saving these variables now before Clover alters them -->
<original.build.finalName>${project.build.finalName}</original.build.finalName>
<original.build.directory>${project.build.directory}</original.build.directory>
</properties>
I then tell all of the subsequent plugins to use these variables instead of the project variables which Clover has altered:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<cacheFile>${original.build.directory}/war/work/webapp-cache.xml</cacheFile>
<outputDirectory>${original.build.directory}</outputDirectory>
<warName>${original.build.finalName}</warName>
<webappDirectory>${original.build.directory}/${original.build.finalName}</webappDirectory>
<workDirectory>${original.build.directory}</workDirectory>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<configurationDir>${original.build.directory}/tomcat7_plugin</configurationDir>
<warDirectory>${original.build.directory}/${original.build.finalName}</warDirectory>
</configuration>
</plugin>
</plugins>
Alternative solutions might include creating or utilizing an additional plugin in a subsequent Maven phase to revert the project.build variables after Clover has finished executing. Either of these solutions is probably better than hard-coding the paths in all of your plugins.
i have downloaded flume from "https://github.com/apache/flume/downloads"..but i am unable to build it..do i need to install thrift first in order to build flume??if so, what is the reson..i am getting following error when i run mvn compile -
mohammad#ubuntu:~/apache-flume-b01a760$ mvn compile
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Flume
[INFO] Flume Core
[INFO] Flume Master Config Web Application
[INFO] Flume Node Web
[INFO] Flume Distribution Project
[INFO] A log4j appender for Flume
[INFO] Flume Hello World Plugin
[INFO] Flume HBase Plugin
[INFO] ------------------------------------------------------------------------
[INFO] Building Flume
[INFO] task-segment: [compile]
[INFO] ------------------------------------------------------------------------
[INFO] No goals needed for project - skipping
[INFO] ------------------------------------------------------------------------
[INFO] Building Flume Core
[INFO] task-segment: [compile]
[INFO] ------------------------------------------------------------------------
[INFO] [antlr3:antlr {execution: default}]
[INFO] ANTLR: Processing source directory /home/mohammad/apache-flume-b01a760/flume-core/src/main/antlr3
ANTLR Parser Generator Version 3.2 Sep 23, 2009 14:05:07
com/cloudera/flume/conf/FlumeDeploy.g
com/cloudera/flume/shell/antlr/FlumeShell.g
[INFO] [antrun:run {execution: generate-version-file}]
[INFO] Executing tasks
main:
[copy] Copying 1 file to /home/mohammad/apache-flume-b01a760/flume-core/target/generated-sources/version/com/cloudera/flume
[INFO] Executed tasks
[INFO] [avro:idl-protocol {execution: default}]
[INFO] [thrift:compile {execution: default}]
[ERROR] thrift failed output:
[ERROR] thrift failed error: /bin/sh: null/bin/thrift: not found
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] thrift did not exit cleanly. Review output for more information.
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7 seconds
[INFO] Finished at: Mon Jun 04 16:10:47 IST 2012
[INFO] Final Memory: 28M/243M
[INFO] ------------------------------------------------------------------------
Flume has some code generation that utilizes thrift as a transport communications serialization mechanism.
In the flume-core/pom.xml, you can see this:
<plugin>
<groupId>org.apache.thrift.tools</groupId>
<artifactId>maven-thrift-plugin</artifactId>
<version>0.1.10</version>
<configuration>
<thriftExecutable>${thrift.executable}</thriftExecutable>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
</plugin>
You need to install thrift, and then configure the location in the parent pom.xml:
<properties>
<!-- NB: The version of the thrift compiler must match that of the dependency
on the jar file below. -->
<thrift.executable>${env.THRIFT_HOME}/bin/thrift</thrift.executable>
<!-- Set default encoding to UTF-8 to remove maven complaints -->
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<!-- defaults for flaky test and focused test exclusions -->
<test.exclude.pattern>$</test.exclude.pattern> <!-- junk pattern -->
<test.include.pattern>**/Test*.java</test.include.pattern>
</properties>
greetings all
i have a web application using (spring-hibernate) frameworks
and when tried to build the application with maven2 using the command mvn install
i get a build successful with the following note:
The following files have NOT been resolved:
[INFO] The following files have NOT been resolved:
[INFO] antlr:antlr:java-source:sources:2.7.7
[INFO] com.sun.jdmk:jmxtools:java-source:sources:1.2.1
[INFO] com.sun.jmx:jmxri:java-source:sources:1.2.1
[INFO] commons-dbcp:commons-dbcp:java-source:sources:1.2.2
[INFO] commons-httpclient:commons-httpclient:java-source:sources:3.1
[INFO] commons-logging:commons-logging:java-source:sources:1.1.0.jboss
[INFO] hibernate-commons-annotations:hibernate-commons-annotations:java-source:sources:3.0.0.GA
[INFO] hsqldb:hsqldb:java-source:sources:1.8.0.2
[INFO] javassist:javassist:java-source:sources:3.4.GA
[INFO] javax.jms:jms:java-source:sources:1.1
[INFO] net.java.dev.stax-utils:stax-utils:java-source:sources:20040917
[INFO] org.apache.solr:solr-commons-csv:java-source:sources:1.3.0
[INFO] org.apache.solr:solr-lucene-analyzers:java-source:sources:1.3.0
[INFO] org.apache.solr:solr-lucene-core:java-source:sources:1.3.0
[INFO] org.apache.solr:solr-lucene-highlighter:java-source:sources:1.3.0
[INFO] org.apache.solr:solr-lucene-queries:java-source:sources:1.3.0
[INFO] org.apache.solr:solr-lucene-snowball:java-source:sources:1.3.0
[INFO] org.apache.solr:solr-lucene-spellchecker:java-source:sources:1.3.0
[INFO] org.apache.velocity:velocity:java-source:sources:1.5
[INFO] org.tuckey:urlrewritefilter:java-source:sources:3.1.0
[INFO] quartz:quartz:java-source:sources:1.6.0
[INFO] stax:stax-api:java-source:sources:1.0.1
what does this mean ?
This looks like output from the maven-dependency-plugin and the 'sources' goal -- it looks like someone has configured the Maven build to pull source artifacts. What this output means is that Maven was unable to find source artifacts in any Maven2 repositories.
http://maven.apache.org/plugins/maven-dependency-plugin/sources-mojo.html
Without being able to see it, I am assuming that your compilation and packaging was successful regardless of these messages.
It comes from the maven-dependency-plugin when you set the execution block when you include a goal to check/list the dependencies while you issue the maven install command.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>install</id>
<phase>install</phase>
<goals>
<goal>source</goal>
</goals>
</execution>
</executions>
</plugin>
You error means one of dependencies is not resolved properly. See all the goals under the maven dependency plugin which contains many other goals to help you manage the version you declare in your POM.