Set maven.compiler.target on command-line
The maven-compiler-plugin allows one to set the maven.compiler.target property in the POM, the value of which is in turn passed as the -target argument to the Java compiler. I would like to be able to set this maven.compiler.target on the command-line instead, as follows: mvn clean compile -Dmaven.compiler.target=1.5 However, when I try this it seems to have no effect on the compiled class files. Furthermore, when I set -Dmaven.compiler.target to some illegal value the build still succeeds and the class files still have the same minor and major version numbers (as shown by javap). All of this leads me to believe that the -Dmaven.compiler.target property being passed on the command-line is being ignored. Is there any way to set the value of the -target compiler parameter from the mvn command-line? -- Jason Voegele Parents often talk about the younger generation as if they didn't have much of anything to do with it.
Maven site error with version range
I have a Maven project that declares a dependency on another Maven artifact using an open ended version range, such as this: org.terracotta.toolkit terracotta-toolkit-1.0 [1.0.0-SNAPSHOT,] (I know that it is to some degree asking for trouble using such version ranges, but for this particular project we have very good reason for doing so.) For the most part this works fine, but when trying to generate the project web site with "mvn site", I get the following error when it tries to create the Dependency Management Report: > [INFO] Generating "Dependency > Management" report. Downloading: > http:/XX/content/groups/public/org/terracotta/toolkit/terracotta-toolkit-1.0/[1.0.0-SNAPSHOT,]/terracotta-toolkit-1.0-[1.0.0-SNAPSHOT,].pom > [INFO] > > [ERROR] FATAL ERROR [INFO] > > [INFO] Invalid uri > 'http://XX/content/groups/public/org/terracotta/toolkit/terracotta-toolkit-1.0/[1.0.0-SNAPSHOT,]/terracotta-toolkit-1.0-[1.0.0-SNAPSHOT,].pom': > escaped absolute path not valid [INFO] > > [INFO] Trace > java.lang.IllegalArgumentException: > Invalid uri > 'http://XX/content/groups/public/org/terracotta/toolkit/terracotta-toolkit-1.0/[1.0.0-SNAPSHOT,]/terracotta-toolkit-1.0-[1.0.0-SNAPSHOT,].pom': > escaped absolute path not valid As you can see from the message, it tries to construct a URI with the open ended version range specification instead of the resolved version number, which of course fails. Can anyone tell me if there is a workaround? Thanks. -- Jason Voegele Did you hear that two rabbits escaped from the zoo and so far they have only recaptured 116 of them? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Error building "bin" assembly
Followup: I can reproduce this error with a very minimal project by using the
maven-arcetype-plugin to create a simple project, and then adding the following
plugin declaration to the POM:
org.apache.maven.plugins
maven-assembly-plugin
2.2
src
bin
${project.build.directory}/site/downloads
site
single
With this plugin declaration in place, I get the error when I execute either
"mvn assembly:single" or "mvn site".
Can anyone provide any clues?
Thanks
On Nov 10, 2010, at 10:02 AM, Jason Voegele wrote:
> I am trying to use the pre-defined "bin" assembly descriptor (descriptorRef)
> and I am getting an error stating that "A tar file cannot include itself."
> I've included a full stack trace below. Does anyone know what might be
> wrong? Is there any other information I should include to help diagnose?
> Thanks.
>
> [INFO] Building tar :
> /Users/jvoegele/projects/terracotta/forge/sparse/tc-maven-plugin/tags/release-1.6.1/target/site/downloads/tc-maven-plugin-1.6.1-bin.tar.gz
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 18.239s
> [INFO] Finished at: Wed Nov 10 09:37:36 EST 2010
> [INFO] Final Memory: 33M/81M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.2:assembly (downloads) on
> project tc-maven-plugin: Failed to create assembly: Error creating assembly
> archive bin: A tar file cannot include itself. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.2:assembly (downloads)
> on project tc-maven-plugin: Failed to create assembly: Error creating
> assembly archive bin: A tar file cannot include itself.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:314)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:132)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create
> assembly: Error creating assembly archive bin: A tar file cannot include
> itself.
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:468)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
> ... 19 more
> Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException:
> Error creating assembly archive bin: A tar file cannot include itself.
> at
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultA
Error building "bin" assembly
I am trying to use the pre-defined "bin" assembly descriptor (descriptorRef) and I am getting an error stating that "A tar file cannot include itself." I've included a full stack trace below. Does anyone know what might be wrong? Is there any other information I should include to help diagnose? Thanks. [INFO] Building tar : /Users/jvoegele/projects/terracotta/forge/sparse/tc-maven-plugin/tags/release-1.6.1/target/site/downloads/tc-maven-plugin-1.6.1-bin.tar.gz [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 18.239s [INFO] Finished at: Wed Nov 10 09:37:36 EST 2010 [INFO] Final Memory: 33M/81M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.2:assembly (downloads) on project tc-maven-plugin: Failed to create assembly: Error creating assembly archive bin: A tar file cannot include itself. -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.2:assembly (downloads) on project tc-maven-plugin: Failed to create assembly: Error creating assembly archive bin: A tar file cannot include itself. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:314) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168) at org.apache.maven.cli.MavenCli.main(MavenCli.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create assembly: Error creating assembly archive bin: A tar file cannot include itself. at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:468) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) ... 19 more Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: Error creating assembly archive bin: A tar file cannot include itself. at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:196) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:409) ... 21 more Caused by: org.codehaus.plexus.archiver.ArchiverException: A tar file cannot include itself. at org.codehaus.plexus.archiver.tar.TarArchiver.execute(TarArchiver.java:202) at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:871) at org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:512) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:192) ... 22 more [ERROR] [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/MojoExecutionException - 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
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
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: org.apache.maven.plugins maven-javadoc-plugin 2.7 true false org.terracotta.toolkit:* 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: EJB 2.0 artifacts
On Tuesday 03 November 2009 11:00:24 am Jason Voegele wrote: > I am converting an Ant project that uses EJB 2.0 classes from the javax.ejb > package (EJBObject, EJBHome, EJBMetaData) to use Maven. The Ant build > works by compiling against an ejb.jar file in the project's lib directory. > For the Maven build, I am wondering if there are any existing Maven > artifacts for EJB 2.0 on any public repository? I've searched around a > bit, and although I've found some artifacts that claim to contain these > javax.ejb classes, they all seem to have them bundled with something else. > Any pointers? Turns out that org.apache.openejb:javaee-api:5.0-1 had what I needed. -- Jason Voegele We're here to give you a computer, not a religion. -- attributed to Bob Pariseau, at the introduction of the Amiga - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
EJB 2.0 artifacts
I am converting an Ant project that uses EJB 2.0 classes from the javax.ejb package (EJBObject, EJBHome, EJBMetaData) to use Maven. The Ant build works by compiling against an ejb.jar file in the project's lib directory. For the Maven build, I am wondering if there are any existing Maven artifacts for EJB 2.0 on any public repository? I've searched around a bit, and although I've found some artifacts that claim to contain these javax.ejb classes, they all seem to have them bundled with something else. Any pointers? Thanks. -- Jason Voegele It has been said that man is a rational animal. All my life I have been searching for evidence which could support this. -- Bertrand Russell - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Concurrent access to local repository by multiple processes
I am wondering if it is now safe to have multiple Maven 2.1.0 processes running concurrently using the same local repository. I know that with older versions of Maven this was certainly not safe, but reading comments on some JIRA issues leads me to believe that this may have been addressed with Maven 2.1.0. Can anyone comment with any amount of certainty? -- Jason Voegele An investment in knowledge always pays the best interest. -- Benjamin Franklin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Build Eclipse plugins with Maven
Hi All, I am just wondering what is the best way to build a set of Eclipse plugins using Maven? Via Google I discovered Tycho, but what I do not like about Tycho is that it is essentially a separate, experimental Maven 3 installation, rather than a plugin for Maven 2. Unfortunately this approach will not work well with some of our continuous integration and publication systems so I have to rule it out. Apart from Tycho, then, what is the recommended approach? -- Jason Voegele Murphy's Law, that brash proletarian restatement of Godel's Theorem. -- Thomas Pynchon, "Gravity's Rainbow" - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Integration testing best practices
I'm interested in knowing the current thinking on best practices for integration testing in Maven projects. I did find a few articles on the Web that discuss this issue, but they all are a bit old now. The most relevant article appears to be this one: http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing "Maven: The Definitive Guide" is curiously silent on this issue. Can anyone point me to some up-to-date discussion of integration testing best practices for Maven? Failing that, would you care to share your thoughts on this mailing list? Thanks. -- Jason Voegele The Gordian Maxim: If a string has one end, it has another. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Central repository for snapshots?
On Friday 13 March 2009 10:15:42 am Marco Huber wrote: > Hi Jason, > > you should add: http://repository.apache.org/snapshots/ > > There lives the snapshots from the apache projects. Thank you, Marco. Works like a charm. -- Jason Voegele "When the going gets tough, the tough get empirical." -- Jon Carroll signature.asc Description: This is a digitally signed message part.
Central repository for snapshots?
Hello all, I am trying to compile the latest trunk version of maven-archetype, which uses maven-parent-11-SNAPSHOT. Of course, this maven-parent-11-SNAPSHOT does not exist in the central repository because it is a SNAPSHOT, and therefore the build fails. Is there a repository I can put in my settings.xml that contains this and other necessary artifacts to build maven-archetype? Thanks. -- Jason Voegele Snow Day -- stay home. signature.asc Description: This is a digitally signed message part.
Re: deploy archetype-catalog
On Thursday 04 December 2008 07:47:32 am Raphaël Piéroni wrote: > Hi, > > Please consider raising a Jira http://jira.codehaus.org/browse/ARCHETYPE-223 -- Jason Voegele Truly great madness can not be achieved without significant intelligence. -- Henrik Tikkanen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: End User License Agreements
On Wednesday 03 December 2008 01:57:53 pm Tomasz Pik wrote: > On Wed, Dec 3, 2008 at 7:51 PM, Jason Voegele <[EMAIL PROTECTED]> wrote: > > Is there any way to make Maven prompt the user to accept a license > > agreement? > > Not yet, see http://jira.codehaus.org/browse/MNG-671 Thanks Tomasz. The last comment on that issue was more than a year ago. Any insight into whether or not the patches will ever be applied, or if license clickthroughs will be otherwise implemented? -- Jason Voegele Nothing is impossible for the man who doesn't have to do it himself. -- A. H. Weiler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: deploy archetype-catalog
On Wednesday 03 December 2008 01:57:48 pm Reto Bachmann-Gmür wrote: > that's what I do (more exactly what continuum does), but while the > archetype gets deployed to the snapshotRepository specified in the > distributionManagement I find no archetype-catalog there. I can confirm this behavior. "mvn deploy" deploys the archetype to the repository, but the archetype-catalog.xml does not get created (or updated) in the deployment repository. -- Jason Voegele Q: What do you call a boomerang that doesn't come back? A: A stick. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
End User License Agreements
We have a need to ask the user to accept a license agreement at the time that Maven downloads and installs some of the artifacts we host on our Maven repository. I have read som information here: http://maven.apache.org/pom.html#Licenses I see that the POM supports a element that allows us to specify the license, but unfortunately it appears that this cannot be used to prompt the user to accept (or decline) the license. Is there any way to make Maven prompt the user to accept a license agreement? Thanks. -- Jason Voegele The idle mind knows not what it is it wants. -- Quintus Ennius - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
