Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
On 11 May 2010 17:16, Markus Muenkel markus.muen...@fernuni-hagen.dewrote: I'm releasing a Maven2 multi-module project. One of the modules is a POM project (assembly project) that uses the maven-assembly-plugin in order to build an assembly (zip archive). The artifacts to be assembled are specified via dependencies in the POM. They point to modules contained in the same multi-module project. When running mvn release:prepare on the multi-module project, the build of the assembly project fails with the message that the dependencies cannot be resolved. These dependencies are reported with the version that should be released, e.g. 0.0.3. Before running the goal, all dependency versions are 0.0.3-SNAPSHOT. What seems to happen is that the snapshot version 0.0.3-SNAPSHOT is replaced by 0.0.3 and then the assembly plugin is started (which is bound to the package phase). what goal did you bind with? It needs to be assembly:single The assembly plugin tries to resolve the dependencies based on version 0.0.3 which however do not yet exist at that point. The exist in the reactor, providing the project in which assembly is being invoked has dependencies on those artifacts so that maven knows the build order must build the dependent projects first. to test if you have this working, here is a simple test procedure: 1. mvn versions:set -DnewVersion=0.0.3-reltesting-SNAPSHOT 2. mvn clean verify 3. mvn versions:rollback it is essential that you only run up the lifecycle as far as verify when testing, as if you go as far as install, the artifacts will have been pushed to the local repo (and hence issues with your reactor will be missed) If you are under the clock [i.e. your manager is saying this needs to be released yesterday, why did you recommend maven, your future at this company is being questioned] then just change the preparationGoals from clean verify to clean install to get a release out the door. But the reality is that such a release can end up with mixed build artifacts, wherein the dependencies copied into your assembly where the ones built during the release:prepare, while the same artifacts copied to your remote repository were built during release:perform... so that if somebody checks say the md5 of the jar inside the assembly against the md5 of that same jar deployed to the maven repo, they will find that the checksums do not match (different timestamps)... additionally, if you use remoteTagging (which you pretty much need to) and somebody commits while release:prepare is running, then the release:perform will checkout different code and the subtle issues of bundled artifact mismatches _will_ bite you in the ass. So what I am saying is that you need to fix it so that your build works with clean verify on a virgin version number (i.e. a version number that has never been built before)... but if time pressures are forced on you, you can get a release out... just don't forget to fix the real problem -Stephen I guess it is not a problem in Maven but I'm missing practice on how to perform a successful release in this situation. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Unexpected reference to an old Repository
On Wed, May 12, 2010 at 5:57 AM, Prout John - jprout john.pr...@acxiom.com wrote: maven1-repository.dev.java.net (https://maven-repository.dev.java.net/repository/) Path to dependency: 1) com.acxiomdigital.iws:IWS-Service:war:8.3.0-5-SNAPSHOT 2) com.acxiomdigital.is.ws:is-ws-service:jar:8.2.0-3 3) com.acxiomdigital.is.cache:is-cache:jar:8.2.0-3 4) com.digitalimpact:factory:jar:8.2.0-31 5) com.digitalimpact:di-common:jar:8.1.0-136 For each of these poms, check to see whether they define the repository. Once a repository is defined (from any pom) it will be used to check all future poms. It's one of the reasons why repository definition is now frowned upon and replaced with repository managers. If you can't find a repository definition in that list, start checking your transitive dependency graph (i.e your project dependencies, then the dependencies of those, etc) I suspect you can edit your ~/.m2/settings.xml and create a mirror for this bad repository. Something like: settings ... mirrors mirror idmaven1-repository.dev.java.net/id namemaven1-repository.dev.java.net/name urlhttp://download.java.net/maven/1//url mirrorOfmaven1-repository.dev.java.net/mirrorOf /mirror - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
war:exploded or alternatives?
Folks; in some cases, we're deploying webapps built as .war files manually to some application server, but in some structure, I'd like to, after install:install has finished, automatically unpack them to some given webapps folder for a local jetty installation for the sake of zipping / deploying the jetty+webapps as a whole. At the moment, I am using a configuration like that... build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId configuration webappDirectory/home/kr/kontext/runtime/appservers/jetty/webapps/jettyweb/webappDirectory /configuration /plugin [...] ... to get the job done, which works, but basically has the flaw that it generally and in any case creates a folder in jetty/webapps/ before building a .war file - which is not what I want as not each of our developers has a local jetty installation (in the same place) available. So to ask: - How to tweak the configuration to have the webapp directory copied out from $PROJECT/target/ to some specialized folder after the war has been built? - How to modify things to make this happen only if I run a given goal for that project (war:explode?) rather than happening automatically along with install:install? TIA and all the best, Kristian - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: war:exploded or alternatives?
add an execution bound to the phase you want and put the configuration of that execution in the execution. On 12 May 2010 08:22, Kristian Rink li...@zimmer428.net wrote: Folks; in some cases, we're deploying webapps built as .war files manually to some application server, but in some structure, I'd like to, after install:install has finished, automatically unpack them to some given webapps folder for a local jetty installation for the sake of zipping / deploying the jetty+webapps as a whole. At the moment, I am using a configuration like that... build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId configuration webappDirectory/home/kr/kontext/runtime/appservers/jetty/webapps/jettyweb/webappDirectory /configuration /plugin [...] ... to get the job done, which works, but basically has the flaw that it generally and in any case creates a folder in jetty/webapps/ before building a .war file - which is not what I want as not each of our developers has a local jetty installation (in the same place) available. So to ask: - How to tweak the configuration to have the webapp directory copied out from $PROJECT/target/ to some specialized folder after the war has been built? - How to modify things to make this happen only if I run a given goal for that project (war:explode?) rather than happening automatically along with install:install? TIA and all the best, Kristian - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: war:exploded or alternatives?
Am 12.05.2010 09:53, schrieb Stephen Connolly:
add an execution bound to the phase you want and put the configuration of
that execution in the execution.
Well, that's what I thought too, and I figured out that calling
war:exploded actually does what I need, with one minor annoyance (which
is what initially made me think): Having this configuration...
[...]
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
webappDirectory/home/kr/kontext/runtime/appservers/jetty/webapps/jettyweb/webappDirectory
/configuration
/plugin
[...]
[...]
in pom.xml, maven does what I intend to do, but in this case, no matter
whether using war:exploded or war:war, the webapp _always_ is built in
the specified webappDirectory. What I want it to do, however, is to
build the webapp (and eventually the .war file) in
${project.home}/target/ as it does by default and _then_, using
war:exploded, unpack the war file to some specified folder outside
${project.home}. So far I failed, however, at configuring
maven-war-plugin for right this behaviour in case of war:exploded being
explicitely called... :/
K.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven triggers cygwin warning
Hi!
Jeremy Bopp jer...@psam.bopp.psam.ten
(psam=spam (remove) ; ten=net)
wrote a small patch for mvn.
Using that I don not get the warning any more.
Here it is:
$ diff -u mvn mvnmodified/mvn-modified
--- mvn 2010-05-12 10:34:19.261049000 +0200
+++ mvnmodified/mvn-modified2010-05-12 10:31:36.0 +0200
@@ -143,11 +143,14 @@
fi
CLASSWORLDS_LAUNCHER=org.codehaus.classworlds.Launcher
+CLASSPATH=`echo ${M2_HOME}/boot/classworlds-*.jar`
# For Cygwin, switch paths to Windows format before running java
if $cygwin; then
[ -n $M2_HOME ]
M2_HOME=`cygpath --path --windows $M2_HOME`
+ [ -n $CLASSPATH ]
+CLASSPATH=`cygpath --path --windows $CLASSPATH`
[ -n $JAVA_HOME ]
JAVA_HOME=`cygpath --path --windows $JAVA_HOME`
[ -n $HOME ]
@@ -156,7 +159,7 @@
exec $JAVACMD \
$MAVEN_OPTS \
- -classpath ${M2_HOME}/boot/classworlds-*.jar \
+ -classpath $CLASSPATH \
-Dclassworlds.conf=${M2_HOME}/bin/m2.conf \
-Dmaven.home=${M2_HOME} \
${CLASSWORLDS_LAUNCHER} $QUOTED_ARGS
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Truncated pom.xml when artifact deployed to local repository
I'm using Maven 2.2.1 in conjunction with Hudson on Linux (OEL 5.3) and it seems that if a project pom.xml is more than 4096 bytes, Hudson only writes up to 4096 bytes when it deploys it to the repository (truncating it in the process). This means that any projects dependent on this one won't build. Any poms less than 4096 bytes seem to deploy fine. This only occurs when the project is built via Hudson as building/deploying is fine using maven my local development machine using the same OS. This probably isn't a maven issue per se but just wondered if anyone else has had this problem? Incidentally I get the same problem on Ubuntu 9.10 so I don't think it's the OS. Perhaps someone could recommend an alternative Continuous Integration Server? Many Thanks. Please visit our website www.greggs.co.uk Greggs plc is a public limited company, registered in England and Wales, registered number 502851, registered office Fernwood House, Clayton Road, Jesmond, Newcastle upon Tyne NE2 1TL. Confidentiality: This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email and highlight the error. Security Warning: Please note that this email has been created in the knowledge that Internet email is not a 100% secure communications medium. We advise that you understand and accept this lack of security when emailing us. Viruses: Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Visit our website at: Http://www.greggs.co.uk This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk
Re: Truncated pom.xml when artifact deployed to local repository
Hi Ross, I saw your http://issues.hudson-ci.org/browse/HUDSON-6370 , and wondered if you had seen (closed, not reproducible) http://jira.codehaus.org/browse/MNG-2551 , which seems similar. Might not help much since it was not resolved. Brett On Wed, May 12, 2010 at 7:39 PM, Ross Hedley (AS400) ross.hed...@greggs.co.uk wrote: I'm using Maven 2.2.1 in conjunction with Hudson on Linux (OEL 5.3) and it seems that if a project pom.xml is more than 4096 bytes, Hudson only writes up to 4096 bytes when it deploys it to the repository (truncating it in the process). This means that any projects dependent on this one won't build. Any poms less than 4096 bytes seem to deploy fine. This only occurs when the project is built via Hudson as building/deploying is fine using maven my local development machine using the same OS. This probably isn't a maven issue per se but just wondered if anyone else has had this problem? Incidentally I get the same problem on Ubuntu 9.10 so I don't think it's the OS. Perhaps someone could recommend an alternative Continuous Integration Server? Many Thanks. Please visit our website www.greggs.co.uk Greggs plc is a public limited company, registered in England and Wales, registered number 502851, registered office Fernwood House, Clayton Road, Jesmond, Newcastle upon Tyne NE2 1TL. Confidentiality: This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email and highlight the error. Security Warning: Please note that this email has been created in the knowledge that Internet email is not a 100% secure communications medium. We advise that you understand and accept this lack of security when emailing us. Viruses: Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Visit our website at: Http://www.greggs.co.uk This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Truncated pom.xml when artifact deployed to local repository
Thanks for your reply Brett. Yes I had seen that. I think my next step is upgrade to java 1.6.0_20 on the build box (it's currently on 1.6.0_16) but I don't think it'll make any difference. I've upgraded to the latest version of Hudson and the svn client just in case but these didn't fix it. After that I guess I'll try the beta of maven 3.0. It's just a shame that this restricts the great features of maven we'd like to start using. Also, I'd like to keep on using Hudson but we may have to change. Cheers. -Original Message- From: Brett Randall [mailto:javabr...@gmail.com] Sent: 12 May 2010 11:20 To: Maven Users List Subject: Re: Truncated pom.xml when artifact deployed to local repository Hi Ross, I saw your http://issues.hudson-ci.org/browse/HUDSON-6370 , and wondered if you had seen (closed, not reproducible) http://jira.codehaus.org/browse/MNG-2551 , which seems similar. Might not help much since it was not resolved. Brett On Wed, May 12, 2010 at 7:39 PM, Ross Hedley (AS400) ross.hed...@greggs.co.uk wrote: I'm using Maven 2.2.1 in conjunction with Hudson on Linux (OEL 5.3) and it seems that if a project pom.xml is more than 4096 bytes, Hudson only writes up to 4096 bytes when it deploys it to the repository (truncating it in the process). This means that any projects dependent on this one won't build. Any poms less than 4096 bytes seem to deploy fine. This only occurs when the project is built via Hudson as building/deploying is fine using maven my local development machine using the same OS. This probably isn't a maven issue per se but just wondered if anyone else has had this problem? Incidentally I get the same problem on Ubuntu 9.10 so I don't think it's the OS. Perhaps someone could recommend an alternative Continuous Integration Server? Many Thanks. Please visit our website www.greggs.co.uk Greggs plc is a public limited company, registered in England and Wales, registered number 502851, registered office Fernwood House, Clayton Road, Jesmond, Newcastle upon Tyne NE2 1TL. Confidentiality: This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email and highlight the error. Security Warning: Please note that this email has been created in the knowledge that Internet email is not a 100% secure communications medium. We advise that you understand and accept this lack of security when emailing us. Viruses: Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Visit our website at: Http://www.greggs.co.uk This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ Please visit our website www.greggs.co.uk Greggs plc is a public limited company, registered in England and Wales, registered number 502851, registered office Fernwood House, Clayton Road, Jesmond, Newcastle upon Tyne NE2 1TL. Confidentiality: This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email and highlight the error. Security Warning: Please note that this email has been created in the knowledge that Internet email is not a 100% secure communications medium. We advise that you understand and accept this lack of security when emailing us. Viruses: Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Visit our website at: Http://www.greggs.co.uk This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit:
RE: Truncated pom.xml when artifact deployed to local repository
Good Afternoon Ross we could benefit from your experience with a short readme.IBM_OLDXXX.txt text file which would enumerate pitfalls you encountered such as: 1)configuring the JVM (which version JVM works on your IBM xxx host?) 2)configuring a repository on your machine..any permissions problems if so how to workaround? 3)which utilities does IBM_OLDXXX install for utilities..ftp/sftp..cp/scp..svn/cvs 4)if a shell is loaded what utilities does IBM_OLDXX install for grep..which..who? 5)how does IBM_OLDXXX handle EBCDIC-ASCII conversion? you may be the only engineer to install and configure a working maven installation on this ibm legacy host! With Sincere Appreciation, Martin Gainty __ Please do not alter/modify or disrupt this transmission. Thank You Subject: RE: Truncated pom.xml when artifact deployed to local repository Date: Wed, 12 May 2010 11:43:30 +0100 From: ross.hed...@greggs.co.uk To: users@maven.apache.org Thanks for your reply Brett. Yes I had seen that. I think my next step is upgrade to java 1.6.0_20 on the build box (it's currently on 1.6.0_16) but I don't think it'll make any difference. I've upgraded to the latest version of Hudson and the svn client just in case but these didn't fix it. After that I guess I'll try the beta of maven 3.0. It's just a shame that this restricts the great features of maven we'd like to start using. Also, I'd like to keep on using Hudson but we may have to change. Cheers. -Original Message- From: Brett Randall [mailto:javabr...@gmail.com] Sent: 12 May 2010 11:20 To: Maven Users List Subject: Re: Truncated pom.xml when artifact deployed to local repository Hi Ross, I saw your http://issues.hudson-ci.org/browse/HUDSON-6370 , and wondered if you had seen (closed, not reproducible) http://jira.codehaus.org/browse/MNG-2551 , which seems similar. Might not help much since it was not resolved. Brett On Wed, May 12, 2010 at 7:39 PM, Ross Hedley (AS400) ross.hed...@greggs.co.uk wrote: I'm using Maven 2.2.1 in conjunction with Hudson on Linux (OEL 5.3) and it seems that if a project pom.xml is more than 4096 bytes, Hudson only writes up to 4096 bytes when it deploys it to the repository (truncating it in the process). This means that any projects dependent on this one won't build. Any poms less than 4096 bytes seem to deploy fine. This only occurs when the project is built via Hudson as building/deploying is fine using maven my local development machine using the same OS. This probably isn't a maven issue per se but just wondered if anyone else has had this problem? Incidentally I get the same problem on Ubuntu 9.10 so I don't think it's the OS. Perhaps someone could recommend an alternative Continuous Integration Server? Many Thanks. Please visit our website www.greggs.co.uk Greggs plc is a public limited company, registered in England and Wales, registered number 502851, registered office Fernwood House, Clayton Road, Jesmond, Newcastle upon Tyne NE2 1TL. Confidentiality: This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email and highlight the error. Security Warning: Please note that this email has been created in the knowledge that Internet email is not a 100% secure communications medium. We advise that you understand and accept this lack of security when emailing us. Viruses: Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Visit our website at: Http://www.greggs.co.uk This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ Please visit our website www.greggs.co.uk Greggs plc is a public limited company, registered in England and Wales,
Re: Truncated pom.xml when artifact deployed to local repository
If you deploy on a local fs the repo must different from your local repository. I think there is an issue regarding this in MNG (http://jira.codehaus.org/browse/MNG-2551). 2010/5/12 Ross Hedley (AS400) ross.hed...@greggs.co.uk: I'm using Maven 2.2.1 in conjunction with Hudson on Linux (OEL 5.3) and it seems that if a project pom.xml is more than 4096 bytes, Hudson only writes up to 4096 bytes when it deploys it to the repository (truncating it in the process). This means that any projects dependent on this one won't build. Any poms less than 4096 bytes seem to deploy fine. This only occurs when the project is built via Hudson as building/deploying is fine using maven my local development machine using the same OS. This probably isn't a maven issue per se but just wondered if anyone else has had this problem? Incidentally I get the same problem on Ubuntu 9.10 so I don't think it's the OS. Perhaps someone could recommend an alternative Continuous Integration Server? Many Thanks. Please visit our website www.greggs.co.uk Greggs plc is a public limited company, registered in England and Wales, registered number 502851, registered office Fernwood House, Clayton Road, Jesmond, Newcastle upon Tyne NE2 1TL. Confidentiality: This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email and highlight the error. Security Warning: Please note that this email has been created in the knowledge that Internet email is not a 100% secure communications medium. We advise that you understand and accept this lack of security when emailing us. Viruses: Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Visit our website at: Http://www.greggs.co.uk This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk -- Olivier http://twitter.com/olamy http://fr.linkedin.com/in/olamy http://www.viadeo.com/fr/profile/olivier.lamy7 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven-Surefire: Unable to run the Junits
Hi All, I am using Surefire to run my Junit tests for Eclipse based plug-ins. I keep getting the following error while running the tests. java.lang.exception no runnable methods Where in a have a TestSuite and the TestSuite has a test class. The test class ends with test and all the methods have @test annotations associated with it. I am using JUnit 4 and Eclipse 3.5. Please help me to resolve the problem. Thanks and Regards, Saurav -- View this message in context: http://old.nabble.com/Maven-Surefire%3A-Unable-to-run-the-Junits-tp28535615p28535615.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Aggregating Javadocs from Dependency Sources
I am trying to generate Javadocs for a project that is conceptually an aggregate of several other projects. I am using the information from this page as a guide: http://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate-dependency-sources.html That page indicates that you can use the includeDependencySources option to have the Javadoc plugin download the source JARs for dependencies and include them in the sources against which Javadocs are generated. However, I am unable to get it to work. The Javadoc plugin does indeed recognize this option, which I can ascertain by the fact that if source JARs for any dependencies are not available it fails with an error. I have tried using both dependencySourceExcludes and dependencySourceIncludes, but no matter how I craft these options the Javadocs for dependencies are never included. When I execute mvn javadoc:jar, for example, I receive a bunch of messages on the terminal indicating that Maven is trying to download javadoc resources but source JARs for dependencies are not downloaded and the generate Javadoc does not include dependency sources. Here is how I have configured the Javadoc plugin in my POM: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.7/version configuration includeDependencySourcestrue/includeDependencySources includeTransitiveDependencySourcesfalse/includeTransitiveDependencySources dependencySourceIncludes dependencySourceIncludeorg.terracotta.toolkit:*/dependencySourceInclude /dependencySourceIncludes /configuration /plugin I've attached the complete POM for your perusal, in case you might find that information helpful, and the output of the mvn javadoc:jar command is also available here: http://paste.ubuntu.com/432246/ Is this a bug in the Javadoc plugin, or am I somehow using it incorrectly? Thanks for any help you can provide. -- Jason Voegele No matter who you are, some scholar can show you the great idea you had was had by someone before you. pom.xml Description: XML document - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Aggregating Javadocs from Dependency Sources
There is something of a best practice of avoiding the aggregation feature of the javadoc plugin, in favor of: 1) create source artifacts for each dependency 2) use dependency plugin to unpack the source artifacts into 'one big tree' 3) run the javadoc plugin on the result tree to produce aggregate javadoc. This is used at Apache CXF, amongst other places. On Wed, May 12, 2010 at 10:03 AM, Jason Voegele ja...@jvoegele.com wrote: I am trying to generate Javadocs for a project that is conceptually an aggregate of several other projects. I am using the information from this page as a guide: http://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate-dependency-sources.html That page indicates that you can use the includeDependencySources option to have the Javadoc plugin download the source JARs for dependencies and include them in the sources against which Javadocs are generated. However, I am unable to get it to work. The Javadoc plugin does indeed recognize this option, which I can ascertain by the fact that if source JARs for any dependencies are not available it fails with an error. I have tried using both dependencySourceExcludes and dependencySourceIncludes, but no matter how I craft these options the Javadocs for dependencies are never included. When I execute mvn javadoc:jar, for example, I receive a bunch of messages on the terminal indicating that Maven is trying to download javadoc resources but source JARs for dependencies are not downloaded and the generate Javadoc does not include dependency sources. Here is how I have configured the Javadoc plugin in my POM: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.7/version configuration includeDependencySourcestrue/includeDependencySources includeTransitiveDependencySourcesfalse/includeTransitiveDependencySources dependencySourceIncludes dependencySourceIncludeorg.terracotta.toolkit:*/dependencySourceInclude /dependencySourceIncludes /configuration /plugin I've attached the complete POM for your perusal, in case you might find that information helpful, and the output of the mvn javadoc:jar command is also available here: http://paste.ubuntu.com/432246/ Is this a bug in the Javadoc plugin, or am I somehow using it incorrectly? Thanks for any help you can provide. -- Jason Voegele No matter who you are, some scholar can show you the great idea you had was had by someone before you. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
release:perform ignores commandline parameters even with -Darguments
Hello, I seem to be having a problem with the release:perform plugin. I need to send a parameter at the commandline such as -Dmy.parameter=my.value. When I do so with every other phase, it is taken into account and works fine (even in the release:prepare phase where I use mvn release:prepare -Dmy.parameter=my.value -Darguments=-Dmy.parameter=my.value). When I try with mvn release:perform -Dmy.parameter=my.value -Darguments=-Dmy.parameter=my.value, it does not work. The release:perform acts as if the parameter was never sent. I've searched the web for such a problem but haven't been able to find an answer. Can anybody help please? Using Maven 2.2.1, using maven-release-plugin version 2.0 Thanks! Be the change that you want to see in the world- Mohandas Karamchand Gandhi
Re: Aggregating Javadocs from Dependency Sources
On Wed, 2010-05-12 at 10:07 -0400, Benson Margulies wrote: There is something of a best practice of avoiding the aggregation feature of the javadoc plugin, in favor of: 1) create source artifacts for each dependency 2) use dependency plugin to unpack the source artifacts into 'one big tree' 3) run the javadoc plugin on the result tree to produce aggregate javadoc. This is used at Apache CXF, amongst other places. Thank you, Benson. This approach seems to work just fine. -- Jason Voegele If you want to get rich from writing, write the sort of thing that's read by persons who move their lips when the're reading to themselves. -- Don Marquis - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven-Surefire: Unable to run the Junits
You should provide more information: - Source code of your test suite - Can you run the suite from Eclipse? - etc. If you asked me to guess, I'd say that for some reason, your tests are run as JUnit3 tests, but there aren't any methods whose name starts with test (because you've used JUnit4-style @Test annotations). Cheers, Peter sauravs wrote: Hi All, I am using Surefire to run my Junit tests for Eclipse based plug-ins. I keep getting the following error while running the tests. java.lang.exception no runnable methods Where in a have a TestSuite and the TestSuite has a test class. The test class ends with test and all the methods have @test annotations associated with it. I am using JUnit 4 and Eclipse 3.5. Please help me to resolve the problem. Thanks and Regards, Saurav -- View this message in context: http://old.nabble.com/Maven-Surefire%3A-Unable-to-run-the-Junits-tp28535615p28538374.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
inheriting and reusing the same plugin for different purposes? doesn't seem to find the right executions
Here's my scenario: I have a large multimodule project whose WARs share
certain dependencies, which are packaged as zips by a few simple assemblies
I wrote.
I am using the maven-dependency-plugin to unpack the contents of these zips
into their destination folders in the webapps.
However, to reduce clutter and minimize maintenance, the majority of the
plugin configuration is in the root POM, like so:
(note that I am using the same plugin twice for two different reasons - is
this valid?)
build
pluginManagement
plugins
...
!-- unpacking of JAVASCRIPT dependencies --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
inheritedtrue/inherited
executions
execution
idunpack-javascripts/id
goals
goalunpack/goal
/goals
phasepackage/phase
configuration
outputDirectory${project.build.directory}/war/scripts/outputDirectory
/configuration
/execution
/executions
/plugin
!-- unpacking of WSDL dependencies --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
inheritedtrue/inherited
executions
execution
idunpack-wsdls/id
goals
goalunpack/goal
/goals
phasegenerate-resources/phase
configuration
outputDirectory${project.build.directory}/war/WEB-INF/wsdl/outputDirectory
/configuration
/execution
/executions
/plugin
/plugins
/pluginManagement
/build
Some WARs need the WSDLs, some need the javascript files, while others don't
need either - it will be up to the developers creating those projects.
Here is an example usage in one of the WARs (note the ID of the execution,
which is expected to be used to merge the whole configuration)
build
plugins
plugin
artifactIdmaven-dependency-plugin/artifactId
groupIdorg.apache.maven.plugins/groupId
inheritedtrue/inherited
executions
execution
idunpack-javascripts/id
/execution
/executions
configuration
artifactItems
artifactItem
artifactIdsk-javascript-token/artifactId
groupIdcom.securekey.javascript/groupId
version${project.version}/version
classifierjavascript/classifier
typezip/type
/artifactItem
/artifactItems
/configuration
/plugin
/plugins
/build
So in general, the plugin configuration in the root POM will enforce some
common things (destination folder, etc), and the usage will actually allow
the developer to select what javascripts they need, without worrying about
other configuration details.
But the problem is when building, it's always the 2nd plugin configuration
in the root POM that gets used, even though I specify the ID in the leaf
POMs; so when I do an overall build, all the javascript files end up in a
WSDL directory, even if I don't reference the WSDL execution at all.
I inverse the order, and the result is the opposite; the javascripts end up
in the right place, but all the WARs that have a WSDL dependency end up with
a scripts directory full of WSDL files.
I was under the impression that the ID is used to merge the configurations
upon building the project, but I'm not seeing this. Is there a way to
specify exactly what configuration to bind to?
Specify two executions within the same plugin causes the same behaviour,
except with both folders.
To generalize, in a multi-module project, how can I use the same plugin for
totally different uses/scenarios?
thanks,
Shan
Re: release:perform ignores commandline parameters even with -Darguments
First off, release:prepare isn't a phase, it's a goal. Secondly, my guess is that you're misdiagnosing the problem. Running release:perform with -X would confirm this. Instead, what I think is happening is that your command line properties aren't being passed to the forked Maven instance. Take a look at http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html. There isn't, AFAIK, a way to pass through command-line properties from release:perform to the forked instance. Instead, what you should do is create a profile and set the properties you want set during a release and then include the profile name in the releaseProfiles property of the release plugin. HTH, Justin On 5/12/10 10:48 AM, Compere, Lydie wrote: Hello, I seem to be having a problem with the release:perform plugin. I need to send a parameter at the commandline such as -Dmy.parameter=my.value. When I do so with every other phase, it is taken into account and works fine (even in the release:prepare phase where I use mvn release:prepare -Dmy.parameter=my.value -Darguments=-Dmy.parameter=my.value). When I try with mvn release:perform -Dmy.parameter=my.value -Darguments=-Dmy.parameter=my.value, it does not work. The release:perform acts as if the parameter was never sent. I've searched the web for such a problem but haven't been able to find an answer. Can anybody help please? Using Maven 2.2.1, using maven-release-plugin version 2.0 Thanks! Be the change that you want to see in the world- Mohandas Karamchand Gandhi - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: release:perform ignores commandline parameters even with -Darguments
Thank you for your help and sorry about the ultra newbie mistakes. In my case though, the value I need to receive at the commandline is never the same... I'll try release:perform -X to get more info and troubleshoot from there. Thx -Original Message- From: Justin Edelson [mailto:justinedel...@gmail.com] Sent: Wednesday, May 12, 2010 1:53 PM To: Maven Users List Subject: Re: release:perform ignores commandline parameters even with -Darguments First off, release:prepare isn't a phase, it's a goal. Secondly, my guess is that you're misdiagnosing the problem. Running release:perform with -X would confirm this. Instead, what I think is happening is that your command line properties aren't being passed to the forked Maven instance. Take a look at http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html. There isn't, AFAIK, a way to pass through command-line properties from release:perform to the forked instance. Instead, what you should do is create a profile and set the properties you want set during a release and then include the profile name in the releaseProfiles property of the release plugin. HTH, Justin On 5/12/10 10:48 AM, Compere, Lydie wrote: Hello, I seem to be having a problem with the release:perform plugin. I need to send a parameter at the commandline such as -Dmy.parameter=my.value. When I do so with every other phase, it is taken into account and works fine (even in the release:prepare phase where I use mvn release:prepare -Dmy.parameter=my.value -Darguments=-Dmy.parameter=my.value). When I try with mvn release:perform -Dmy.parameter=my.value -Darguments=-Dmy.parameter=my.value, it does not work. The release:perform acts as if the parameter was never sent. I've searched the web for such a problem but haven't been able to find an answer. Can anybody help please? Using Maven 2.2.1, using maven-release-plugin version 2.0 Thanks! Be the change that you want to see in the world- Mohandas Karamchand Gandhi - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: release:perform ignores commandline parameters even with -Darguments
On 5/12/10 2:04 PM, Compere, Lydie wrote: Thank you for your help and sorry about the ultra newbie mistakes. Didn't mean to suggest this was a newbie mistake. The bits of Maven which do forked execution are always a bit tricky. And, to make my point, I completely forgot about passing the arguments parameter. You should be able to do -Darguments=-Dmy.parameter=my.value (note the quotes!) Justin In my case though, the value I need to receive at the commandline is never the same... I'll try release:perform -X to get more info and troubleshoot from there. Thx -Original Message- From: Justin Edelson [mailto:justinedel...@gmail.com] Sent: Wednesday, May 12, 2010 1:53 PM To: Maven Users List Subject: Re: release:perform ignores commandline parameters even with -Darguments First off, release:prepare isn't a phase, it's a goal. Secondly, my guess is that you're misdiagnosing the problem. Running release:perform with -X would confirm this. Instead, what I think is happening is that your command line properties aren't being passed to the forked Maven instance. Take a look at http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html. There isn't, AFAIK, a way to pass through command-line properties from release:perform to the forked instance. Instead, what you should do is create a profile and set the properties you want set during a release and then include the profile name in the releaseProfiles property of the release plugin. HTH, Justin On 5/12/10 10:48 AM, Compere, Lydie wrote: Hello, I seem to be having a problem with the release:perform plugin. I need to send a parameter at the commandline such as -Dmy.parameter=my.value. When I do so with every other phase, it is taken into account and works fine (even in the release:prepare phase where I use mvn release:prepare -Dmy.parameter=my.value -Darguments=-Dmy.parameter=my.value). When I try with mvn release:perform -Dmy.parameter=my.value -Darguments=-Dmy.parameter=my.value, it does not work. The release:perform acts as if the parameter was never sent. I've searched the web for such a problem but haven't been able to find an answer. Can anybody help please? Using Maven 2.2.1, using maven-release-plugin version 2.0 Thanks! Be the change that you want to see in the world- Mohandas Karamchand Gandhi - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven-Surefire: Unable to run the Junit
Hi Peter,
Thanks for the reply.
(a) Code for the test suite for the eclipse
code
@RunWith(Suite.class)
@SuiteClasses( {ExtensionTest.class,EditorTest.class} )
public class BaseFrameworkTestSuite {
}
/code
(b) The suite runs successfully from the Eclipse.
I think the tests are being run as Junit-4.Where exactly do you want me to
look in for that?.
Becuase other Junit 4 tests which are in other plug-ins are running fine.
Best Regards,
Saurav
Peter Niederwieser wrote:
You should provide more information:
- Source code of your test suite
- Can you run the suite from Eclipse?
- etc.
If you asked me to guess, I'd say that for some reason, your tests are run
as JUnit3 tests, but there aren't any methods whose name starts with
test (because you've used JUnit4-style @Test annotations).
Cheers,
Peter
sauravs wrote:
Hi All,
I am using Surefire to run my Junit tests for Eclipse based plug-ins.
I keep getting the following error while running the tests.
java.lang.exception no runnable methods
Where in a have a TestSuite and the TestSuite has a test class.
The test class ends with test and all the methods have @test annotations
associated with it.
I am using JUnit 4 and Eclipse 3.5.
Please help me to resolve the problem.
Thanks and Regards,
Saurav
--
View this message in context:
http://old.nabble.com/Maven-Surefire%3A-Unable-to-run-the-Junits-tp28535615p28539454.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Maven Exec hangs when running a daemon.
I am trying to start a process in the background during the pre-integration-test phase using exec plugin and run some tests against the process. But unfortunately when I try to start the process, Maven build hangs up. Is there any way I can start the process in the background? Thanks -- View this message in context: http://old.nabble.com/Maven-Exec-hangs-when-running-a-daemon.-tp28539557p28539557.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven-Surefire: Unable to run the Junit
Do you have classes with 'Test' in the name, but without any @Test
annotations - e.g..test helper classes
Surefire has the (stupid) habit of treating all classes with 'Test' in
the name as test classes.
See
http://jira.codehaus.org/browse/SUREFIRE-482
Christoph
Am 12.05.2010 20:23, schrieb sauravs:
Hi Peter,
Thanks for the reply.
(a) Code for the test suite for the eclipse
code
@RunWith(Suite.class)
@SuiteClasses( {ExtensionTest.class,EditorTest.class} )
public class BaseFrameworkTestSuite {
}
/code
(b) The suite runs successfully from the Eclipse.
I think the tests are being run as Junit-4.Where exactly do you want me to
look in for that?.
Becuase other Junit 4 tests which are in other plug-ins are running fine.
Best Regards,
Saurav
Peter Niederwieser wrote:
You should provide more information:
- Source code of your test suite
- Can you run the suite from Eclipse?
- etc.
If you asked me to guess, I'd say that for some reason, your tests are run
as JUnit3 tests, but there aren't any methods whose name starts with
test (because you've used JUnit4-style @Test annotations).
Cheers,
Peter
sauravs wrote:
Hi All,
I am using Surefire to run my Junit tests for Eclipse based plug-ins.
I keep getting the following error while running the tests.
java.lang.exception no runnable methods
Where in a have a TestSuite and the TestSuite has a test class.
The test class ends with test and all the methods have @test annotations
associated with it.
I am using JUnit 4 and Eclipse 3.5.
Please help me to resolve the problem.
Thanks and Regards,
Saurav
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Unexpected reference to an old Repository
Thanks for the suggestions! I've been through all the dependencies referenced through the tree below and been unable to find any references to maven1-repository.dev.java.net, so no luck there. What I've found is that my problems are caused by recent releases of Maven. I had problems using Maven 2.2.1 and 2.0.11, but when I regress to 2.0.9 (which is what's installed on our build server) the problem goes away. For now, I'll stick to using Maven 2.0.9, but I'd appreciate any insight as to why recent versions of Maven 2 are causing my build to look at maven1-repository.dev.java.net Thanks John -Original Message- From: Barrie Treloar [mailto:baerr...@gmail.com] Sent: Wednesday, May 12, 2010 12:13 AM To: Maven Users List Subject: Re: Unexpected reference to an old Repository On Wed, May 12, 2010 at 5:57 AM, Prout John - jprout john.pr...@acxiom.com wrote: maven1-repository.dev.java.net (https://maven-repository.dev.java.net/repository/) Path to dependency: 1) com.acxiomdigital.iws:IWS-Service:war:8.3.0-5-SNAPSHOT 2) com.acxiomdigital.is.ws:is-ws-service:jar:8.2.0-3 3) com.acxiomdigital.is.cache:is-cache:jar:8.2.0-3 4) com.digitalimpact:factory:jar:8.2.0-31 5) com.digitalimpact:di-common:jar:8.1.0-136 For each of these poms, check to see whether they define the repository. Once a repository is defined (from any pom) it will be used to check all future poms. It's one of the reasons why repository definition is now frowned upon and replaced with repository managers. If you can't find a repository definition in that list, start checking your transitive dependency graph (i.e your project dependencies, then the dependencies of those, etc) I suspect you can edit your ~/.m2/settings.xml and create a mirror for this bad repository. Something like: settings ... mirrors mirror idmaven1-repository.dev.java.net/id namemaven1-repository.dev.java.net/name urlhttp://download.java.net/maven/1//url mirrorOfmaven1-repository.dev.java.net/mirrorOf /mirror - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org *** The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank You. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: getting multiple forms of the build date
On 4/28/2010 11:53 AM, Marshall Schor wrote: There's a new way to get the build date, documented here: http://maven.apache.org/guides/introduction/introduction-to-the-pom.html - search for maven.build.timestamp. This is nice. I would like to have multiple versions of this. For instance, the whole date/time spec for including in Jar Manifests, and just the month and year for substituting in to documentation publication date. Is there a way to get multiple, different formats for this? I couldn't find one. I found one ref that used a groovy script with the gmaven plugin to do this, and it worked, but was slow, because it has to load up groovy. So, I wrote my first maven plugin. It takes a series of specs which are the simple date and time patterns strings described in the Java class SimpleDateFormat API, and sets the value(s) into property names that are also passed in as part of the configuration. Works like a charm, and is very fast. -Marshall -Marshall - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Reporting API version 3.0 and Maven Reporting Implementation 2.0.5 + 2.1 Released
The Maven team is pleased to announce the release of the Maven Reporting API version 3.0 and Maven Reporting Implementation 2.0.5 + 2.1. Maven Reporting API version 3.0 is the reporting API version decoupled from Maven core version: every reporting plugin should update its dependency to this version. http://maven.apache.org/shared/maven-reporting-api http://maven.apache.org/shared/maven-reporting-impl Release Notes - Maven Shared Components - Version maven-reporting-api 3.0 ** Improvement * [MSHARED-149] - add MavenMultiPageReport to maven-reporting-api Release Notes - Maven Shared Components - Version maven-reporting-impl 2.0.5 ** Improvement * [MSHARED-151] - upgrade maven-reporting-api to 3.0 (decoupled from Maven core version) ** Task * [MSHARED-152] - change svn branch to maven-reporting-impl-2.0.x Release Notes - Maven Shared Components - Version maven-reporting-impl 2.1 ** Bug * [MSHARED-120] - No single report generated with latest maven-reporting- impl ** Improvement * [MSHARED-151] - upgrade maven-reporting-api to 3.0 (decoupled from Maven core version) ** Task * [MSHARED-107] - Update to Doxia 1.1.1 * [MSHARED-119] - Review the Doxia Sink calls Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Clean Plugin 2.4.1 Released
The Maven team is pleased to announce the release of the Maven Clean Plugin, version 2.4.1. This plugin is used to clean the project output directories. Please see the plugin's site for more details: http://maven.apache.org/plugins/maven-clean-plugin/ To use the updated plugin in your projects, you need to add the following snippet to the plugins or plugin management section of your POM: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clean-plugin/artifactId version2.4.1/version /plugin Release Notes - Maven 2.x Clean Plugin - Version 2.4.1 ** Bug * [MCLEAN-44] - NullPointerException when using empty exclude to preserve base directory of fileset ** New Feature * [MCLEAN-43] - Mark clean plugin as @threadSafe Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven-Surefire: Unable to run the Junit
Right, that's another likely cause I've battled with in the past. Now my bet is on this one. :-) Christoph Kutzinski wrote: Do you have classes with 'Test' in the name, but without any @Test annotations - e.g..test helper classes -- View this message in context: http://old.nabble.com/Maven-Surefire%3A-Unable-to-run-the-Junits-tp28535615p28542411.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven-Surefire: Unable to run the Junit
Thanks again Peter and Christoph for the replies. Nope i dont have any helper classes. I had looked at the surefire bug earlier but of to no avail. I do have helper methods with no test annotations but i dont think that has this ability to create this havoc :). Peter Niederwieser wrote: Right, that's another likely cause I've battled with in the past. Now my bet is on this one. :-) Christoph Kutzinski wrote: Do you have classes with 'Test' in the name, but without any @Test annotations - e.g..test helper classes -- View this message in context: http://old.nabble.com/Maven-Surefire%3A-Unable-to-run-the-Junits-tp28535615p28543499.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
