plugin's descriptor contains the wrong g/a/v
I have a plugin containing a number of custom lifecycles, which has always worked well. After upgrade to 2.2.1 (from 2.0.x), I get the following error. What does it mean ? [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager getting plugin 'com.agfa.maven.plugins:maven-lifecycle-plugin': Plugin 'com. agfa.maven.plugins:maven-lifecycle-plugin:0.0.14' has an invalid descriptor: 1) Plugin's descriptor contains the wrong group ID: org.apache.maven.plugins 2) Plugin's descriptor contains the wrong artifact ID: maven-help-plugin 3) Plugin's descriptor contains the wrong version: 2.0.2 [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager getting plugin 'com.agfa.ma ven.plugins:maven-lifecycle-plugin': Plugin 'com.agfa.maven.plugins:maven-lifecycle-plugin:0.0.14' has an invalid descri ptor: 1) Plugin's descriptor contains the wrong group ID: org.apache.maven.plugins 2) Plugin's descriptor contains the wrong artifact ID: maven-help-plugin 3) Plugin's descriptor contains the wrong version: 2.0.2 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.loadPluginFully(DefaultLifecycleExecutor.java:1586) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.findArtifactTypeHandlersInPlugins(DefaultLifecycleExecuto r.java:1468) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.findExtensions(DefaultLifecycleExecutor.java:222) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:178) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.PluginManagerException: Plugin 'com.agfa.maven.plugins:maven-lifecycle-plugin:0.0.14' has an invalid descriptor: 1) Plugin's descriptor contains the wrong group ID: org.apache.maven.plugins 2) Plugin's descriptor contains the wrong artifact ID: maven-help-plugin 3) Plugin's descriptor contains the wrong version: 2.0.2 at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:330) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:224) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:184) at org.apache.maven.plugin.DefaultPluginManager.loadPluginFully(DefaultPluginManager.java:1626) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.loadPluginFully(DefaultLifecycleExecutor.java:1582) ... 15 more - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: plugin's descriptor contains the wrong g/a/v
I'm not sure what you mean by 'the groupId...'. There are 20 lifecyles and hundreds of plugins in the components.xml. The maven-help-plugin is not mentioned. On Tue, Sep 8, 2009 at 10:46 AM, Anders Hammarand...@hammar.net wrote: The error message says that there are errors in the plugin descriptor. What's the groupId and artifactId in the descriptor? /Anders On Tue, Sep 8, 2009 at 10:35, Tom Huybrechts tom.huybrec...@gmail.comwrote: I have a plugin containing a number of custom lifecycles, which has always worked well. After upgrade to 2.2.1 (from 2.0.x), I get the following error. What does it mean ? [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager getting plugin 'com.agfa.maven.plugins:maven-lifecycle-plugin': Plugin 'com. agfa.maven.plugins:maven-lifecycle-plugin:0.0.14' has an invalid descriptor: 1) Plugin's descriptor contains the wrong group ID: org.apache.maven.plugins 2) Plugin's descriptor contains the wrong artifact ID: maven-help-plugin 3) Plugin's descriptor contains the wrong version: 2.0.2 [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager getting plugin 'com.agfa.ma ven.plugins:maven-lifecycle-plugin': Plugin 'com.agfa.maven.plugins:maven-lifecycle-plugin:0.0.14' has an invalid descri ptor: 1) Plugin's descriptor contains the wrong group ID: org.apache.maven.plugins 2) Plugin's descriptor contains the wrong artifact ID: maven-help-plugin 3) Plugin's descriptor contains the wrong version: 2.0.2 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.loadPluginFully(DefaultLifecycleExecutor.java:1586) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.findArtifactTypeHandlersInPlugins(DefaultLifecycleExecuto r.java:1468) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.findExtensions(DefaultLifecycleExecutor.java:222) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:178) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.PluginManagerException: Plugin 'com.agfa.maven.plugins:maven-lifecycle-plugin:0.0.14' has an invalid descriptor: 1) Plugin's descriptor contains the wrong group ID: org.apache.maven.plugins 2) Plugin's descriptor contains the wrong artifact ID: maven-help-plugin 3) Plugin's descriptor contains the wrong version: 2.0.2 at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:330) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:224) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:184) at org.apache.maven.plugin.DefaultPluginManager.loadPluginFully(DefaultPluginManager.java:1626) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.loadPluginFully(DefaultLifecycleExecutor.java:1582) ... 15 more - 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: plugin's descriptor contains the wrong g/a/v
The plugin.xml seems fine: plugin descriptiona plugin that defines all lifecycles for custom AGFA plugins/description groupIdcom.agfa.maven.plugins/groupId artifactIdmaven-lifecycle-plugin/artifactId version0.0.14/version goalPrefixlifecycle/goalPrefix isolatedRealmfalse/isolatedRealm inheritedByDefaulttrue/inheritedByDefault mojos/ dependencies/ /plugin The content matches what is used in the POM and the location in the repository. The only content of this plugin is a components.xml file with LifecycleMapping and ArtifactHandler components. It is added in my root POM as a plugin with extensionstrue/extensions. I just noticed that there is also a build/extensions element containing the maven-help-plugin mentioned in the error message. No idea why it's there, probably just a copy/paste error. If I remove this, everything works fine. So everything's fine for me now, but this is still a small regression from 2.0.x to 2.2.1. thanks, Tom On Tue, Sep 8, 2009 at 12:04 PM, Brett Porterbr...@apache.org wrote: Yes, this happens if the plugin gets built as one coordinate, and deployed to the repository as another. Usually that's just a version out of place but this seems to be more significant. Can you inspect the META-INF/maven/plugin.xml file in the plugin JAR? - Brett On 08/09/2009, at 7:54 PM, Anders Hammar wrote: I'm just reading the error message. What's in the plugin descriptor of your plugin com.agfa.maven.plugins:maven-lifecycle-plugin:0.0.14? I'm not really sure what you mean by 20 lifecycles. Are you talking about the phases? I guess you have a normal Maven plugin which is bound by default to a lifecycle phase? /Anders On Tue, Sep 8, 2009 at 11:03, Tom Huybrechts tom.huybrec...@gmail.comwrote: I'm not sure what you mean by 'the groupId...'. There are 20 lifecyles and hundreds of plugins in the components.xml. The maven-help-plugin is not mentioned. On Tue, Sep 8, 2009 at 10:46 AM, Anders Hammarand...@hammar.net wrote: The error message says that there are errors in the plugin descriptor. What's the groupId and artifactId in the descriptor? /Anders On Tue, Sep 8, 2009 at 10:35, Tom Huybrechts tom.huybrec...@gmail.com wrote: I have a plugin containing a number of custom lifecycles, which has always worked well. After upgrade to 2.2.1 (from 2.0.x), I get the following error. What does it mean ? [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager getting plugin 'com.agfa.maven.plugins:maven-lifecycle-plugin': Plugin 'com. agfa.maven.plugins:maven-lifecycle-plugin:0.0.14' has an invalid descriptor: 1) Plugin's descriptor contains the wrong group ID: org.apache.maven.plugins 2) Plugin's descriptor contains the wrong artifact ID: maven-help-plugin 3) Plugin's descriptor contains the wrong version: 2.0.2 [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager getting plugin 'com.agfa.ma ven.plugins:maven-lifecycle-plugin': Plugin 'com.agfa.maven.plugins:maven-lifecycle-plugin:0.0.14' has an invalid descri ptor: 1) Plugin's descriptor contains the wrong group ID: org.apache.maven.plugins 2) Plugin's descriptor contains the wrong artifact ID: maven-help-plugin 3) Plugin's descriptor contains the wrong version: 2.0.2 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.loadPluginFully(DefaultLifecycleExecutor.java:1586) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.findArtifactTypeHandlersInPlugins(DefaultLifecycleExecuto r.java:1468) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.findExtensions(DefaultLifecycleExecutor.java:222) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:178) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.PluginManagerException: Plugin 'com.agfa.maven.plugins:maven-lifecycle-plugin:0.0.14' has an invalid
Re: how to stop pom downloads
Did you deploy a pom too ? On Wed, Mar 4, 2009 at 11:48 PM, Davis Ford davisf...@zenoconsulting.biz wrote: Hi, we have an internal repo here (using Archiva), and I manually deployed some jars to it. However, whenever I run a maven command it is constantly trying to check the pom against the server version. Example: Downloading: http://internal-maven-repo:8080/archiva/repository/internal//weblogic/webservices/9.2/webservices-9.2.pom This keeps repeating and it is really slow. I noticed that jars that I pulled from the Internet and cached in Archiva it does not do this for. Is there some way to stop it from doing this? Why does it appear to do it only for the jars I manually deployed? Thanks in advance, Davis -- Zeno Consulting, Inc. home: http://www.zenoconsulting.biz blog: http://zenoconsulting.wikidot.com p: 248.894.4922 f: 313.884.2977 - 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: What is current status of repositorytools-plugin ?
Dead. On Wed, Sep 3, 2008 at 11:40 AM, Insitu [EMAIL PROTECTED] wrote: Hello, The question is in the title... -- Arnaud Bailly, PhD OQube - Software Engineering http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is current status of repositorytools-plugin ?
I contributed it to the sandbox a long time ago, but have not looked at it since. The repository copying worked in some cases, but certainly not all. If you want to use it but find bugs, please be prepared to fix them yourself. I would also recommend to look at the stage plugin to see if this fits your needs. Tom On Wed, Sep 3, 2008 at 2:41 PM, Martin Gainty [EMAIL PROTECTED] wrote: are you talking about the economy? could you be more specific what the issue is? has the project been archived? Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Date: Wed, 3 Sep 2008 13:36:52 +0200 From: [EMAIL PROTECTED] To: users@maven.apache.org Subject: Re: What is current status of repositorytools-plugin ? Dead. On Wed, Sep 3, 2008 at 11:40 AM, Insitu [EMAIL PROTECTED] wrote: Hello, The question is in the title... -- Arnaud Bailly, PhD OQube - Software Engineering http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ See how Windows Mobile brings your life together—at home, work, or on the go. http://clk.atdmt.com/MRT/go/msnnkwxp1020093182mrt/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: handling .jars not in public repositories?
I haven't tried it , but I think you could just use a POM packaging
(which only does install/deploy) and attach the jar with build-helper.
On Wed, Jul 16, 2008 at 11:14 AM, Stephen Connolly
[EMAIL PROTECTED] wrote:
Yeah, I wish I knew how to disable the jar plugin... that's why I
posted the antrun solution!
On Wed, Jul 16, 2008 at 7:54 AM, Kristian Rink [EMAIL PROTECTED] wrote:
Stephen;
and first off, thanks a bunch for your hints on that, much appreciated
(and indeed quite a bit enlightening):
Stephen Connolly schrieb:
[...]
plugins
!-- fake out maven and install the binary artifact --
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
goals
goalrun/goal
/goals
configuration
tasks
copy
file=${basedir}/src/main/jar/${pom.artifactId}-${pom.version}.jar
tofile=${basedir}/target/${pom.artifactId}-${pom.version}.jar
overwrite=true/
/tasks
/configuration
/execution
/executions
/plugin
/plugins
[...]
On Wed, Jul 16, 2008 at 7:45 AM, Stephen Connolly
[EMAIL PROTECTED] wrote:
I would do a simple trickery...
disable the jar plugin and then use the build-helper plugin to attach
the jar file.
Is any of the two approaches to be preferred in the given use case?
Personally, from my current point of knowledge, though, I'd go for
antrun simply because so far I have never disabled a plugin in maven2
and am not sure I know how to get that done. ;)
Cheers thanks again,
Kristian
--
Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/
jab: [EMAIL PROTECTED] * icq: 48874445 * fon: ++49 176 2447 2771 One
dreaming alone, it will be only a dream; many dreaming together is the
beginning of a new reality. (Hundertwasser)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: release plugin without SCM
The plugin at https://svn.dev.java.net/svn/hudson/branches/tom/plugins/staging/maven-stagingrelease-plugin/ has a set-version goal, which you could use to create your own release process. On Tue, Jul 8, 2008 at 5:57 PM, Kallin Nagelberg [EMAIL PROTECTED] wrote: Is there a way to use the release plugin without invoking the SCM activities? (I'm using SVN) The release plugin doesn't seem to be compatible with my project's branching strategy for a number of reasons: 1) It seems to always want to release from the trunk. Sometimes we need to release from branches. 2.) Releasing a non-module nested component doesn't work. Say I have a project in myproject/reports, and I just want to release reports. I'm getting the error 'myproject/tags/reports-1.0' doesn't exist. I would be happy just using the deploy goal directly, but I can't because I need to change the version of the project throughout multiple POMs. Any ideas? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SURVEY] How does your team retrieve artifacts?
I use HTTP for ordinary development. However file is also used often in tooling. For example I have a custom release plugin that deploys to a file based staging repository. Only when the release completely succeeds, is the staging repository uploaded (using the staging plugin) to the real repository. This buys me atomic releases (because release:perform does fail sometimes even if release:prepare didn't). On Wed, May 21, 2008 at 8:15 AM, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, I'm just trying to get some data on what protocol is used to retrieve artifacts. This question strictly relates to what you use for retrieval. Most people I have seen use a web server or a shared network drive, but I'd like to get some feedback. [ ] Our team uses HTTP to retrieve our artifacts [ ] Our team intends to use HTTP to retrieve our artifacts [ ] Our team uses the filesystem [ ] Our team does not use HTTP or the filesystem because please say what protocol you use and the reason Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A language that doesn't affect the way you think about programming is not worth knowing. — Alan Perlis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reply protocol for this list?
On Fri, May 2, 2008 at 7:48 PM, Wendy Smoak [EMAIL PROTECTED] wrote: On Fri, May 2, 2008 at 7:39 AM, Russell Bateman [EMAIL PROTECTED] wrote: I wondered, because based on the traffic I've watched the last couple of days since I joined I've not detected a specific pattern, if there's a best practice for replies to postings in this list. I've given up on the top-posting thing. Even getting people to properly quote only the relevant bits seems to be a lost cause. I blame GMail. ;) Switch to GMail and you won't notice anymore ;) tom -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API to figure out the exact URL of a deployed artifact?
new DefaultArtifactRepository(id, url, layout) ? On Mon, Apr 28, 2008 at 8:49 PM, Dan Tran [EMAIL PROTECTED] wrote: It turns out I need to instantiate a new ArtifactRepository with a new basedir ( the built-in localRepository does not allow me to change the basedir, ie not setting method ) Any clue on how to create what I need? Thanks -D On Fri, Apr 25, 2008 at 12:51 PM, Brian E. Fox [EMAIL PROTECTED] wrote: If you wanted to create a new repository layout implementation, you could probably create a new ArtifactRepository instance with this layout and hand it to the resolver. -Original Message- From: Mark Struberg [mailto:[EMAIL PROTECTED] Sent: Friday, April 25, 2008 1:53 PM To: Maven Users List Subject: Re: API to figure out the exact URL of a deployed artifact? Problem is that (as far as i know) the ArtifactResolver asks the 'local Repository' to give you the artifact. And wagon and other mechanisms in the background perform all the necessary work to get the file to your local repo first. But this is exactly what Dan tries to avoid! The file must not be in the local repo, since this would blew it up. LieGrü, strub --- Tom Huybrechts [EMAIL PROTECTED] schrieb: Unless I'm missing something, you could just use an ArtifactResolver. See section Creating and resolving an artifact in the mojo developer cookbook. http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook Tom On Fri, Apr 25, 2008 at 5:20 AM, Dan Tran [EMAIL PROTECTED] wrote: Hello, I would like to write a generic mojo to download a deployed artifact with given groupId, artifactId, and version as params. For snapshot, i like to get the latest one. I spent some times with deploy plugin hoping for a clue but not finding any thing yet. Suggestions are greatly appreciated. Thanks -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gesendet von Yahoo! Mail. Mehr Möglichkeiten, in Kontakt zu bleiben. http://de.overview.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to preserve the file name running deploy:deploy-file ?
No. You cannot change the repository layout. The file name of an artifact is part of that layout. On Sat, Apr 26, 2008 at 7:58 PM, Stefano Nichele [EMAIL PROTECTED] wrote: Hi all, running: mvn deploy:deploy-file -Durl=myurl -Dfile=my-file.tgz -Dpackaging=tgz -DgroupId=mygroup -DartifactId=myartifact -Dersion=3.5.1 -DrepositoryId=private the file my-file.tgz is deployed, but in the repository I have: mygroup |myartifact | 3.5.1 | myartifact-3.5.1.tgz that is the artifcatId is used also as filename. Is there a way to change the file name ? I would like to preserve the original one (my-file.tgz) Thnaks in advance Ste - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API to figure out the exact URL of a deployed artifact?
Unless I'm missing something, you could just use an ArtifactResolver. See section Creating and resolving an artifact in the mojo developer cookbook. http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook Tom On Fri, Apr 25, 2008 at 5:20 AM, Dan Tran [EMAIL PROTECTED] wrote: Hello, I would like to write a generic mojo to download a deployed artifact with given groupId, artifactId, and version as params. For snapshot, i like to get the latest one. I spent some times with deploy plugin hoping for a clue but not finding any thing yet. Suggestions are greatly appreciated. Thanks -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API to figure out the exact URL of a deployed artifact?
No, ArtifactResolver.resolve() will actually download the artifact using Wagon. On Fri, Apr 25, 2008 at 7:52 PM, Mark Struberg [EMAIL PROTECTED] wrote: Problem is that (as far as i know) the ArtifactResolver asks the 'local Repository' to give you the artifact. And wagon and other mechanisms in the background perform all the necessary work to get the file to your local repo first. But this is exactly what Dan tries to avoid! The file must not be in the local repo, since this would blew it up. LieGrü, strub --- Tom Huybrechts [EMAIL PROTECTED] schrieb: Unless I'm missing something, you could just use an ArtifactResolver. See section Creating and resolving an artifact in the mojo developer cookbook. http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook Tom On Fri, Apr 25, 2008 at 5:20 AM, Dan Tran [EMAIL PROTECTED] wrote: Hello, I would like to write a generic mojo to download a deployed artifact with given groupId, artifactId, and version as params. For snapshot, i like to get the latest one. I spent some times with deploy plugin hoping for a clue but not finding any thing yet. Suggestions are greatly appreciated. Thanks -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gesendet von Yahoo! Mail. Mehr Möglichkeiten, in Kontakt zu bleiben. http://de.overview.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API to figure out the exact URL of a deployed artifact?
One of the arguments to resolve() is an ArtifactRepository object for your local repository. So you can decide on the base dir of the local repository, but below that the default layout would still be used. If you want to go even further, you can write your own ArtifactRepositoryLayout and use that to create a DefaultArtifactRepository. Doing that I think you can control the target location completely. On Fri, Apr 25, 2008 at 8:58 PM, Dan Tran [EMAIL PROTECTED] wrote: can I get ArtifactResolver.resolve() to download the artfiact to some other location then local repo? -D On Fri, Apr 25, 2008 at 11:36 AM, Tom Huybrechts [EMAIL PROTECTED] wrote: No, ArtifactResolver.resolve() will actually download the artifact using Wagon. On Fri, Apr 25, 2008 at 7:52 PM, Mark Struberg [EMAIL PROTECTED] wrote: Problem is that (as far as i know) the ArtifactResolver asks the 'local Repository' to give you the artifact. And wagon and other mechanisms in the background perform all the necessary work to get the file to your local repo first. But this is exactly what Dan tries to avoid! The file must not be in the local repo, since this would blew it up. LieGrü, strub --- Tom Huybrechts [EMAIL PROTECTED] schrieb: Unless I'm missing something, you could just use an ArtifactResolver. See section Creating and resolving an artifact in the mojo developer cookbook. http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook Tom On Fri, Apr 25, 2008 at 5:20 AM, Dan Tran [EMAIL PROTECTED] wrote: Hello, I would like to write a generic mojo to download a deployed artifact with given groupId, artifactId, and version as params. For snapshot, i like to get the latest one. I spent some times with deploy plugin hoping for a clue but not finding any thing yet. Suggestions are greatly appreciated. Thanks -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gesendet von Yahoo! Mail. Mehr Möglichkeiten, in Kontakt zu bleiben. http://de.overview.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to configure the maven-jar-plugin to use a prefix for classes?
I don't think so. But you can control the classesDirectory. So you could configure project.build.outputDirectory to be target/classes/prefix and override this in the jar plugin back to target/classes... On Fri, Apr 25, 2008 at 9:42 PM, mraible [EMAIL PROTECTED] wrote: Is it possible to configure the maven-jar-plugin to use a prefix for classes? I want to put them in a directory other than the root. Thanks, Matt -- View this message in context: http://www.nabble.com/Is-it-possible-to-configure-the-maven-jar-plugin-to-use-a-prefix-for-classes--tp16904340s177p16904340.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple artifact handlers being use at a reactor level
I've had a similar issues when using different extensions that provide lifecycles in the same build. My solution was to write my own maven plugin that contained all the lifecycles I needed (copy/paste from the original), and only use that plugin as an extension. On Wed, Apr 16, 2008 at 8:47 PM, Apaar Trivedi [EMAIL PROTECTED] wrote: I have basically pasted this from the irc channel: In a reactor, is it possible that the first artifacthandler that gets used will be used for all subsequent modules that get run? Even if those modules provide their own artifacthandler? Because that is what's going on in my build. I have module foo that gets run using the default handler (nothing specified), then my next module bar, which is built using a plugin we provided which configures its own artifacthandler, doesnt seem to get that handler, hence it comes out in the incorrect packaging type (this is howI know it's not using the specific plugins handler.) But if i move module bar which uses the plugin with specific handler before module foo, then it gets the correct packaging type (in this case a zip file). Is this a known issue or what? Thanks Apaar Trivedi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: continuous integration server
Hudson, without a doubt. See https://hudson.dev.java.net/ or a live instance at http://hudson.jboss.org/hudson/ On Sun, Apr 13, 2008 at 1:36 PM, Peter Horlock [EMAIL PROTECTED] wrote: Hi, Which continuous integration server would you recommend me? Continuum? Or is there also a version by sonatype in the making?! :-) Thanks in advance, Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: continuous integration server
Kohsuke keeps it simple, yet very powerful. You can have Hudson installed and your first build running within minutes. If you need customization, it is also incredibly easy to extend via plugins. Just try it, you'll never look back... On Sun, Apr 13, 2008 at 2:26 PM, Peter Horlock [EMAIL PROTECTED] wrote: could you tell me your reason why you prefer hudson? Thanks, Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository search order
Be careful with the jboss repository. It contains artifacts that have the same groupId, artifactId and version as artifacts in central, but with different content. Mixing both is asking for trouble... Tom On Fri, Apr 11, 2008 at 3:58 PM, Glynbach [EMAIL PROTECTED] wrote: Hi I added the jboss repository to my POM to add a jta dependecy. But running mvn test gives an error retrieving the jta jar. The error shows maven is trying to get the jar from the maven repository (which exists but has no jar in it) rather than the jboss repository. Can I stipulate which repository should be used in the dependency? pom entries are : project repositories repository idjboss/id urlrepository.jboss.com/maven2/url /repository /repositories .. dependency groupIdjavax.transaction/groupId artifactIdjta/artifactId version1.0.1B/version /dependency .. In the console I can see the following output: -- 1 required artifact is missing. for artifact: com.fdar.apress.s2:app:war:1.0-SNAPSHOT from the specified remote repositories: jboss (repository.jboss.com/maven2), central (http://repo1.maven.org/maven2) and also: url = http://repo1.maven.org/maven2 Downloading: http://repo1.maven.org/maven2/javax/transaction/jta/1.0.1B/jta-1.0.1B.jar [ERROR] Thanks for any help -- View this message in context: http://www.nabble.com/Repository-search-order-tp16627819s177p16627819.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about download.meter and maven2
Use -B On Thu, Apr 3, 2008 at 10:30 PM, Lacoste, Dana (TSG Software San Diego) [EMAIL PROTECTED] wrote: OK, from the archives, I can run mvn with -Dmaven.download.meter=bootstrap (for example) and I won't get the Downloading 1/123k updating to 2/123k etc. But this doesn't appear to work in maven2 This causes issues because I'm running in a scripted environment (Cruise Control) on multiple platforms at once, and it ends up displaying the following in the log file: 1/123K2/123K3/123K4/123K etc. It's very long. One of the artifacts it's downloading is several megabytes in size and the log file ends up being several paragraphs of download notifications. I can see in maven-core/src/main/java/org/apache/maven/cli/ConsoleDownloadMonitor.java the transferProgress function call that's printing out the offensive messages, but I can't figure out (I don't know how maven's plugin hierarchy works well enough) how to disable it, short of editing the maven source myself and removing that one line. I don't want to run mvn -q because I really DO want all the other output, I just don't want that one KIND of output, much like worked in maven 1. Can anyone provide any suggestions? Googling hasn't helped (yet!) Thanks, Dana Lacoste - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I want to run install even if my tests fail
-Dmaven.test.failure.ignore=true On Wed, Apr 2, 2008 at 8:19 PM, Sommers, Elizabeth [EMAIL PROTECTED] wrote: Won't work because I want to run the tests (I am trying to attach cobertura data). I am looking for a property I can set at build time that allows me to ignore failed tests and just continue to install. -Original Message- From: Siarhei Dudzin [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 02, 2008 2:11 PM To: Maven Users List Subject: Re: I want to run install even if my tests fail or 'mvn install -Dmaven.test.skip=true' Siarhei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exclude module from deploy phase
You could set an altDeploymentRepository for this specific project, and let it point to a dummy local location. On Mon, Mar 31, 2008 at 9:18 PM, Andrew Uhm [EMAIL PROTECTED] wrote: Hello, Is it possible to configure a module to be excluded from the mvn deploy phase? For instance, in a single project I have 3 modules: Domain Repository Web My domain and repository modules are dependencies to other projects, but the web module is not. The web module tends to be rather large (80-90M) as it contains all dependent jars and a grip of images, and so my site maven repository is growing at an alarming rate. My project parent pom file: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance; xs i:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion parent groupIdcom.mycomp.commons/groupId artifactIdComp-commons-parent/artifactId version1.6.0-SNAPSHOT/version /parent properties commons.parent.version1.6.0-SNAPSHOT/commons.parent.version search.version1.10.0-SNAPSHOT/search.version combine.version1.12.0-SNAPSHOT/combine.version /properties groupIdcom.mycomp.site/groupId artifactIdComp-site-parent/artifactId version1.13.0-SNAPSHOT/version packagingpom/packaging nameSite Parent Project Model/name scm connectionscm:svn: http://testtools02.la3.mycomp.com/svn/repos/site/trunk/connection developerConnectionscm:svn: http://testtools02.la3.mycomp.com/svn/repos/site/trunk/developerConnection urlhttp://testtools02.la3.mycomp.com/fisheye/browse/site/url /scm modules moduleComp-site-domain/module moduleComp-site-repository/module moduleComp-site-web/module moduleComp-site-integration-tests/module moduleComp-site-acceptance-tests/module /modules . /project I appreciate your help, Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there a way to deploy project without configuring pom.xml
You can use -DaltDeploymentRepository=... http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html On Mon, Mar 17, 2008 at 9:40 PM, Néstor Boscán [EMAIL PROTECTED] wrote: I put it inside settings.xml and I get: distributionManagement repository idrepo/id nameRepository/name urldav:http://someurl/maven2/url /repository snapshotRepository idrepo/id nameRepository/name urldav:http://someurl/maven2/url /snapshotRepository /distributionManagement Error reading settings.xml: Unrecognised tag: 'distributionManagement' (position : START_TAG seen .../activeProfiles\r\n --\r\n distributionManagement.. . @241:29) Line: 241 Column: 29 What I need is to set this on a PC level and not at POM level. Regards, Néstor Boscán -Mensaje original- De: news [mailto:[EMAIL PROTECTED] En nombre de Jan Torben Heuer Enviado el: Lunes, 17 de Marzo de 2008 08:36 a.m. Para: users@maven.apache.org Asunto: Re: Is there a way to deploy project without configuring pom.xml Néstor Boscán wrote: Hi Is there a way to deploy the project to a remote repository without configuring distributionManagement inside the pom.xml. Can I do this on the settings.xml or pass the info on the command? Yes, it works here fine with the settings.xml. we don't have distributionManagement inside our pom.xml Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: question about maven-rar-plugin
And all these other packagings are defined in maven-core too. http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven-core/src/main/resources/META-INF/plexus/components.xml?revision=522316view=markup On Feb 4, 2008 10:13 PM, Olivier Lamy [EMAIL PROTECTED] wrote: Hi, Have try defining this in your pom packagingrar/packaging ? rar packaging is define in maven core. -- Olivier 2008/2/4, Stephen Connolly [EMAIL PROTECTED]: Why does this plugin not define a packaging of type rar? All the other JavaEE plugins: war, ear, ejb, etc define a packaging. What was the rational behind having this behave differently? Thanks, -Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: update/creation of maven-metadata.xml file
On Jan 29, 2008 5:32 PM, Wendy Smoak [EMAIL PROTECTED] wrote: On Jan 26, 2008 4:20 PM, nadias [EMAIL PROTECTED] wrote: Will this work deploy-file or just deploy? I am working with deploy-file but it is not updating the metadata even if I specify this parameter. The updateReleaseInfo parameter is not listed for the deploy-file goal. * http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html Vote for it! http://jira.codehaus.org/browse/MDEPLOY-52 :) This seems to make it impossible to deploy a working plugin with deploy:deploy-file. The 'latest' and 'release' elements seem to be required, or Maven complains that it can't find the plugin at all. :( If you specify an explicit version in your POM, I would think that Maven always finds it ? Tom -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: update/creation of maven-metadata.xml file
On Jan 29, 2008 5:52 PM, Wendy Smoak [EMAIL PROTECTED] wrote: On Jan 29, 2008 9:44 AM, Tom Huybrechts [EMAIL PROTECTED] wrote: If you specify an explicit version in your POM, I would think that Maven always finds it ? Probably, (and that's definitely a best practice,) but not everything uses a pom. 'mvn archetype:create' comes to mind, for example... as well as 'mvn deploy:deploy-file' itself. It's ugly, but mvn org.apache.maven.plugins:maven-archetype-plugin:version:create would work here too. Tom Some corporate environments require approvals and manual deployment of every artifact into their internal repos to tightly control what is available. I don't see a way to deploy a plugin with the correct metadata until MDEPLOY-52 is fixed. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to trace which repository files are used in a build?
The most reliable (and least readable) way is to run with the '-X' option and look at the classpath in the configuration of the compiler or surefire plugin. Tom On Jan 27, 2008 5:30 PM, EJ Ciramella [EMAIL PROTECTED] wrote: You can try mvn site which should give SOME of this, but other reporting plugins give more accurate info, like: http://maven.apache.org/plugins/maven-dependency-plugin/index.html - look at the list option or http://maven.apache.org/plugins/maven-project-info-reports-plugin/depend ency-convergence-mojo.html -Original Message- From: sebb [mailto:[EMAIL PROTECTED] Sent: Sunday, January 27, 2008 11:01 AM To: users@maven.apache.org Subject: How to trace which repository files are used in a build? Is there a debug flag or other method which can be used to trace which files are accessed from the repository during a Maven 2 build? One could empty the local repository before starting a build, and look for the download messages, but hopefully there is an easier method... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: update/creation of maven-metadata.xml file
-DupdateReleaseInfo=true On Jan 26, 2008 1:40 AM, nadias [EMAIL PROTECTED] wrote: How can I force the maven-metadata.xml file to be updated (or created) when deploying plugins? I have an instance where the maven-metadata.xml is not being updated or created when deploying plugins - it seems that deploying plugins may be different from deploying artifacts. Any help is appreciated. Thanks. -- View this message in context: http://www.nabble.com/update-creation-of-maven-metadata.xml-file-tp15100044s177p15100044.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-release-plugin / release:prepare goal in batch mode with customized values
http://www.nabble.com/batch-release-of-a-set-of-projects-without-using-the-default-versioning-scheme-to11067663.html#a11067663 maybe that helps On Jan 22, 2008 2:08 PM, Julien CARSIQUE [EMAIL PROTECTED] wrote: Hello, Is there no answer for this need ? I saw a similar question in mail titled release-plugin: additional options for automation Thanks for help, Julien Julien CARSIQUE a écrit : Hello, I would like to automate more my releasing process. How can I feed release:prepare goal with the needed values ? I know --batch-mode but it uses the default inputs for the versions and tag information. Is it using the -Darguments=version_tag new_version ? Thanks, Julien -- Julien CARSIQUE, Nuxeo (Paris, France) Open Source Enterprise Content Management - http://www.nuxeo.org/ Nuxeo EP 5: extensible, Java EE and standards based ECM Platform http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: section MANIFEST
http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html http://maven.apache.org/shared/maven-archiver/index.html#class_manifestSection On Jan 22, 2008 5:06 PM, Arthur Rodrigues Stilben [EMAIL PROTECTED] wrote: How can I insert a section in MANIFEST? Arthur Rodrigues Stilben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release:prepare no javadoc generation
Turn of the release profile. If you still want sources, you'll have to add them yourself. http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html#useReleaseProfile On Jan 20, 2008 10:56 AM, Vytautas Čivilis [EMAIL PROTECTED] wrote: Hi. When using release:prepare plugin, it parses javadocs and generates java doc html files. Is it possible to turn that off? Thanks! vyc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange problems with mvn release:perform when running javadoc:jar on Windows
I've had my share of javadoc problems, but not this one. Did you try to run the javadoc command itself from the commandline ? Tom On Jan 18, 2008 10:48 AM, Stephen Connolly [EMAIL PROTECTED] wrote: Anyone??? or will i just file an issue On Jan 17, 2008 8:24 AM, Stephen Connolly [EMAIL PROTECTED] wrote: Here is the stacktrace: The exact same commands from my machine work with the exact same proxyHost and proxyPort and JDK and Maven version [INFO] [javadoc:jar] [DEBUG] C:\Java\jdk1.6.0_04\jre\..\bin\javadoc.exe -J-DproxyHost=.com -J-DproxyPort= @options @packages Loading source files for package com.... Constructing Javadoc information... Standard Doclet version 1.6.0_04 Building tree for all the packages and classes... Generating C:/work/jsr-112-workmanager-impl/target/apidocs\com/___/___/___//\_.html... [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error while creating archive:Exit code: 1 - java.lang.IllegalArgumentException at sun.net.www.ParseUtil.decode(ParseUtil.java:189) at sun.misc.URLClassPath$FileLoader.init(URLClassPath.java:953) at sun.misc.URLClassPath$3.run(URLClassPath.java:326) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.URLClassPath.getLoader(URLClassPath.java:320) at sun.misc.URLClassPath.getLoader(URLClassPath.java:297) at sun.misc.URLClassPath.findResource(URLClassPath.java:144) at java.net.URLClassLoader$2.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findResource(URLClassLoader.java:359) at java.lang.ClassLoader.getResource(ClassLoader.java:977) at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1159) at javax.xml.parsers.SecuritySupport$4.run(SecuritySupport.java:96) at java.security.AccessController.doPrivileged(Native Method) at javax.xml.parsers.SecuritySupport.getResourceAsStream( SecuritySupport.java:89) at javax.xml.parsers.FactoryFinder.findJarServiceProvider( FactoryFinder.java:250) at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:223) at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java :128) at com.sun.tools.doclets.internal.toolkit.builders.LayoutParser.parseXML( LayoutParser.java:72) at com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build( ClassBuilder.java:108) at com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles( HtmlDoclet.java:155) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles ( AbstractDoclet.java:164) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration( AbstractDoclet.java:106) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start( AbstractDoclet.java:64) at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java :42) at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) 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 com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:215) at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:91) at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) at com.sun.tools.javadoc.Start.begin(Start.java:128) at com.sun.tools.javadoc.Main.execute(Main.java:41) at com.sun.tools.javadoc.Main.main(Main.java:31) com.sun.tools.doclets.internal.toolkit.util.DocletAbortException at com.sun.tools.doclets.internal.toolkit.builders.LayoutParser.parseXML( LayoutParser.java:79) at com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build( ClassBuilder.java:108) at com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles( HtmlDoclet.java:155) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles ( AbstractDoclet.java:164) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration( AbstractDoclet.java:106) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start( AbstractDoclet.java:64) at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java :42) at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) 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
Re: Add source folder
http://mojo.codehaus.org/build-helper-maven-plugin/usage.html On Jan 7, 2008 1:48 PM, Jan Torben Heuer [EMAIL PROTECTED] wrote: How can I add another sourcefolder? (/src/extended/java/) The setting should be recognized by maven-eclipse-plugin and the built process. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add source folder
On Jan 7, 2008 5:19 PM, Kallin Nagelberg [EMAIL PROTECTED] wrote: I would say, theoretically, it should. However, to accomplish it properly, it would have to execute the given pom and analyze the results to see what source folders are being looked at... Afer all, any plugin could be jumping in and adding source folders, even without having them declared anywhere in the pom. This is indeed a problem. That's why the eclipse:eclipse goal is supposed to run the lifecycle up to generate-resources first (@execute phase=generate-resources), so plugins have a change to add source folders. Can you verify that this indeed happens - and that the goal to add the source folder is run before generate-resources ? Tom There is also the problem where you have non-java sources. I am using groovy in my project, and IDEA/eclipse does not recognize that as a source folder via the pom. I would suggest you do what I did, and split your multi-source artifact into two seperate ones. If they are heavily dependant on each other, you may wish to factor out the dependencies into a third module which could be depended on by your two new artifacts. Alternatively, you could just tell everyone on your team to go add the appropriate source folders manually whenever they open a project. On Jan 7, 2008 9:16 AM, Jan Torben Heuer [EMAIL PROTECTED] wrote: Kallin Nagelberg wrote: I was using this plugin for a bit to add an additional source directory, but intellij IDEA does not recognize the additional source. I ended up having to create a new artifact for the second set of sources. eclipse (or the maven-eclipse-plugin) does not add the sourcefolder as well. Or should it? Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where did the maven-embedder go?
[1] I am trying to use the maven-artifact API to download artifacts from my maven repository. Trouble is, I cannot find the formal way to create ArtifactRepository objects. http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook - create a DefaultArtifactRepository object - or have it injected in a plugin field Tom Regards, Graham --
Re: Where did the maven-embedder go?
You can find snapshots here: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/maven-embedder/2.1-SNAPSHOT/ Use the ueber jar, that includes all the dependencies. I think you can still use new DefaultArtifactRepository() with the embedder, as mentioned in the mojo developer cookbook. On Jan 4, 2008 9:49 PM, Nick Stolwijk [EMAIL PROTECTED] wrote: I don't think it is in the maven repo yet, as Maven 2.1 is not released yet. The trunk version is here: https://svn.apache.org/repos/asf/maven/components/trunk/maven-embedder/ Hth, Nick Stolwijk Graham Leggett wrote: Nick Stolwijk wrote: It seems it got deleted between 2.0.5 and 2.0.6 with the following checkins: r521488 | jvanzyl | 2007-03-22 22:56:42 +0100 (Thu, 22 Mar 2007) | 3 lines Changed paths: D /maven/components/branches/maven-2.0.x/maven-embedder o i looked at trying to back port and it's not worth it the trunk version is light years ahead and the alpha 2.1 will be out shortly. Anyone know where I might find the trunk version in svn, or even better, in the maven repo? Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support of ant 1.6+ conditions
Maybe specifying a upgraded dependency/ on ant for the antrun plugin in your POM would help too ? On Jan 3, 2008 2:57 PM, EJ Ciramella [EMAIL PROTECTED] wrote: Is there a newer version of the maven-antrun-plugin? We would like to pass long a true/false property. If I have: condition property=is.preview istrue property=preview/ /condition I get this error: Class org.apache.tools.ant.taskdefs.condition.IsTrue doesn't support the property attribute Any suggestions?
Re: an mvn setup:diagnose would be nice at times like this :)
The UnknownHostException make this look like a network issue. Can you do a ping repo1.maven.org ? Tom On Dec 29, 2007 1:26 PM, Pete Carapetyan [EMAIL PROTECTED] wrote: Long time Maven user getting the dreaded plugin does not exist or no valid version could be found on every maven call after unrelated software installation. Any advice where to look next greatly appreciated. Ran on same box 2 hours before, runs on every other box same network connection, only thing different is I installed some screen capturing software (Camtasia) which might have done something - don't know how to diagnose what. Everything else on the box still running great far as I can tell. Here is what I have done to make sure it isn't the usual suspects. - no proxy - other computer works fine as did this one two hours earlier - no firewall - turned off firewall to test that - installed bran new latest version of maven, pointed to fresh empty repository - virgin conf/settings.xml - ran archetype:create to make sure it wasn't a lame pom.xml in an existing project Below is example of what I ran and what came back (blowing away repository first). It does go as far as to build one maven-metadata-central.xml in ~\.m2\repository\org\apache\maven\plugins then it quits and prints the stacktrace below. $ mvn -X archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -D archetypeArtifactId=maven-archetype-site -DgroupId=org.artofillusion -Darti factId=maven-sample + Error stacktraces are turned on. Maven version: 2.0.8 Java version: 1.6.0_01 OS name: windows xp version: 5.1 arch: x86 Family: windows [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and Settin gs\Administrator\.m2\plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: 'c:\dev\apache-maven-2 .0.8\conf\plugin-registry.xml' [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. [DEBUG] Loading plugin prefixes from group: org.apache.maven.plugins [INFO] org.apache.maven.plugins: checking for updates from central [WARNING] repository metadata for: 'org.apache.maven.plugins' could not be retri eved from repository: central due to an error: Error transferring file [INFO] Repository 'central' will be blacklisted [DEBUG] Exception org.apache.maven.wagon.TransferFailedException: Error transferring file at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputD ata(LightweightHttpWagon.java:104) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(D efaultWagonManager.java:462) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMeta data(DefaultWagonManager.java:363) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetada taManager.resolveAlways(DefaultRepositoryMetadataManager.java:364) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetada taManager.resolve(DefaultRepositoryMetadataManager.java:97) at org.apache.maven.plugin.DefaultPluginMappingManager.loadPluginMapping s(DefaultPluginMappingManager.java:103) at org.apache.maven.plugin.DefaultPluginMappingManager.loadPluginMapping s(DefaultPluginMappingManager.java:87) at org.apache.maven.plugin.DefaultPluginMappingManager.getByPrefix (Defau ltPluginMappingManager.java:61) at org.apache.maven.plugin.DefaultPluginManager.getPluginDefinitionForPr efix(DefaultPluginManager.java:150) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor (DefaultLifecycleExecutor.java:1451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListBy AggregationNeeds(DefaultLifecycleExecutor.java:386) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLi fecycleExecutor.java:138) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java :315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java :430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: java.net.UnknownHostException: repo1.maven.org at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177) at java.net.Socket.connect(Socket.java:519)
Re: an mvn setup:diagnose would be nice at times like this :)
Take a look at your java network settings too - maybe that has a proxy
configured ?
Tom
On Dec 29, 2007 7:06 PM, Stuart McCulloch [EMAIL PROTECTED]
wrote:
On 30/12/2007, Pete Carapetyan [EMAIL PROTECTED] wrote:
As you can imagine I have double, triple and quadruple checked
everything I could think of xp and norton firewall wise, don't know
anything else to check. Which is why I only half jokingly titled this
thread as mvn setup:diagnose would be nice at times like this. This
is such a huge plague on the maven community, it isems really
questionable for it to be so challenging to run diagnostics.
Stack traces are great for errors that are not expected, but this
happens to a lot of people a lot of times from a lot of different
causes, one of which is apparently eluding me now.
have you tried running a simple Java app, such as:
//==
import java.net.InetAddress;
public class getByName {
public static void main(String[] args) throws Exception {
if (args.length 0) {
System.out.println(InetAddress.getByName(args[0]));
} else {
System.out.println(java getByName host);
}
}
}
//==
to make sure that this isn't an application permissions/access issue?
example: java getByName repo1.maven.org
result: repo1.maven.org/63.246.20.112
( did Camtasia change the JAVA_HOME setting, or install a new JVM? )
On Dec 29, 2007 8:47 AM, Jerome Lacoste [EMAIL PROTECTED] wrote:
On Dec 29, 2007 1:39 PM, Pete Carapetyan [EMAIL PROTECTED]
wrote:
answer is inline below question:
On Dec 29, 2007 6:30 AM, Tom Huybrechts [EMAIL PROTECTED]
wrote:
The UnknownHostException make this look like a network issue. Can
you do a
ping repo1.maven.org ?
$ ping repo1.maven.org
Pinging repo1.maven.org [63.246.20.112] with 32 bytes of data:
Reply from 63.246.20.112: bytes=32 time=46ms TTL=52
Reply from 63.246.20.112: bytes=32 time=46ms TTL=52
Reply from 63.246.20.112: bytes=32 time=44ms TTL=52
Reply from 63.246.20.112: bytes=32 time=45ms TTL=52
Ping statistics for 63.246.20.112:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 44ms, Maximum = 46ms, Average = 45ms
Things that comes to mind:
* firewall or anti-virus
* something bad under %HOME%\.m2
You said you tried those, but I would tripple check (maybe you have 2
firewalls on the machine ? XP + separate one ? :)
If you have multiple users on that machine, try with them.
Jerome
PS: do you really log as Administrator on your machine ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Cheers, Stuart
Re: How to avoid CVS files being packaged?
This explains how to include/exclude resources: http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html I thought CVS files where by default excluded in all plugins. Do you already override the includes/excludes in configuration ? Tom On Dec 28, 2007 7:11 AM, amit kumar [EMAIL PROTECTED] wrote: Hi, I can see CVS files being packaged in the WAR builds of maven, while the JAR files are clean and don't have CVS files. How to avoid the CVS files being packaged in WARs/EARs? Regards, Amit Kumar
Re: How to turn off the downloading of http://repo1.maven.org/maven2...?
http://maven.apache.org/guides/mini/guide-mirror-settings.html On Dec 27, 2007 3:33 PM, Thomas Chang [EMAIL PROTECTED] wrote: Hi all, every time if I run mvn commands such as mvn eclipse:eclipse, it will download from the mirror site http://repo1.maven.org/maven2 How can I tuern off this so that it just looks for dependencies from my mirror site on the server maschine? Regards Thomas - Ihr erstes Baby? Holen Sie sich Tipps von anderen Eltern.
Re: [m2] addition resources to an ear?
just put in src/main/application ?
On Dec 27, 2007 5:39 PM, Mick Knutson [EMAIL PROTECTED] wrote:
Is this not possible? I really have a Oc4j requirement that I need to add
an
orion-application.xml into my ear. Can someone please help me add this?
On Dec 26, 2007 12:47 PM, Mick Knutson [EMAIL PROTECTED] wrote:
I have this in my ear's pom.xml
resources
resource
directory${basedir}/src/main/resources/directory
targetPathMETA-INF/targetPath
filteringtrue/filtering
/resource
/resources
but my orion.xml inside ${basedir}/src/main/resources does not get
included into my ear.
Can anyone help please?
--
Thanks,
Mick Knutson
http://www.baselogic.com
http://www.blincmagazine.com
http://www.djmick.com
http://www.myspace.com/mickknutson
http://www.myspace.com/BLiNCMagazine
http://tahoe.baselogic.com
---
--
Thanks,
Mick Knutson
http://www.baselogic.com
http://www.blincmagazine.com
http://www.djmick.com
http://www.myspace.com/mickknutson
http://www.myspace.com/BLiNCMagazine
http://tahoe.baselogic.com
---
Re: Project Version
Try ${plugin.version}. Not sure if it works, but it doesn't hurt to try.
On Dec 27, 2007 10:06 PM, Kallin Nagelberg [EMAIL PROTECTED]
wrote:
I believe what is happening here has to do with my plugin haviing the
'@requiresProject false' attribute set.
On Dec 27, 2007 4:01 PM, Kallin Nagelberg [EMAIL PROTECTED]
wrote:
I'm trying to write a plugin in which I need to access the version of
the
plugin while it's running. I've tried using ${project.version} within my
plugin, but it always resolves to '2.0', as if it is obtaining the maven
version. Does anyone know a way to obtain the version of the plugin?
Re: M2 Repo for Apache Sandbox stuff?
http://maven.apache.org/guides/development/guide-plugin-snapshot-repositories.html On Dec 27, 2007 9:35 PM, Manos Batsis [EMAIL PROTECTED] wrote: Is there a repository for sandbox artifacts publicly available? I'm trying to play a bit with some sandbox stuff like the maven-linkcheck-plugin and really want to avoid the manual labour of checking dependencies out from SVN manually to build and install in my local repo. Thanks! Manos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: distributing files / set of files to remove server (maven wagon plugin ???)
If you need to deploy to application servers, take a look at Cargo. http://cargo.codehaus.org/ On Dec 26, 2007 9:56 PM, Jerome Lacoste [EMAIL PROTECTED] wrote: Hei, anyone knows if there's an easy and generic way to distribute a file or a set of files to a remote server ? Basically, I am searching for something that would wrap wagon and understand the concept of server(s) (so that connection information doesn't need to be in the POM). The use case is for http://jira.codehaus.org/browse/MWEBSTART-25 Cheers, -- Jerome Lacoste - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to mvn deploy artifacts with packagingatlassian-plugin/packaging
On Dec 25, 2007 1:06 AM, Dan Hardiker [EMAIL PROTECTED] wrote:
Tom Huybrechts wrote:
I'm assuming you have the source, and want to build and deploy it
(opposed
to having a binary and wanting do to a deploy-file).
Correct, I am trying to deploy my atlassian-plugin (essentially just a
plain old JAR) into a maven2 repository along with the other libraries.
I just don't know how to tell maven2 what to do.
There should be a maven plugin that defines the atlassian-plugin
packaging.
This plugin would define a mapping from atlassian-plugin to a lifecycle
(which defines which plugins are run) and an artifact type (which says
that
the extension is .jar). In order for these mappings to be picked up, you
need to specify extensionstrue/extensions on that maven plugin.
Correct, the plugin is atlassian-pdk, described below.
If that doesn't work, try sending us some more info than 'it doesn't
work'.
Some output (with -X), a pom, ...
By all means, it's difficult to preempt what you want (from my
perspective), however a mvn -X deploy gives a 4975 line output please
confirm that you want this before I just paste it in here, I searched
for the word deploy and this is what I found around the only instance:
{noformat}
this realm = plexus.core
urls[0] = file:/java/m2/lib/maven- core-2.0.7-uber.jar
urls[1] = file:/java/m2/lib/svnkit-1.1.4-hudson-4.jar
urls[2] = file:/java/m2/lib/wagon-svn-1.6.jar
urls[3] =
file:/Users/dhardiker/.m2/repository/org/jvnet/wagon-svn/wagon-svn/1.6/wagon-
svn-1.6.jar
Number of imports: 0
-
[DEBUG] atlassian-pdk: resolved to version 2.1.1 from repository
atlassian-m2-plugins
[INFO]
[INFO] Building Adaptavist Theme Builder
[INFO]task-segment: [deploy]
[INFO]
[DEBUG] Error looking up lifecycle mapping to retrieve optional mojos.
Lifecycle ID: default. Error: Component descriptor cannot be found in
the component repository:
org.apache.maven.lifecycle.mapping.LifecycleMappingatlassian-plugin.
org.codehaus.plexus.component.repository.exception.ComponentLookupException:
Component descriptor cannot be found in the component repository:
org.apache.maven.lifecycle.mapping.LifecycleMappingatlassian-plugin.
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(
DefaultPlexusContainer.java :323)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(
DefaultPlexusContainer.java:440)
at
org.apache.maven.execution.MavenSession.lookup(MavenSession.java:123)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.findOptionalMojosForLifecycle(
DefaultLifecycleExecutor.java:)
{noformat}
... the pom is a standard pom, but with
packagingatlassian-plugin/packaging and the following plugin added
in the build section:
plugins
plugin
groupIdcom.atlassian.maven.plugins/groupId
artifactIdatlassian-pdk/artifactId
extensionstrue/extensions
/plugin
/plugins
(if you want the whole pom.xml, then by all means I can paste it in here
on request)
The plugin basically does some work during the process-classes phase,
which modifies the target/classes before compilation and packaging. The
resulting jar should be treated the same as if the packaging was jar.
I wrote some of the innards of that plugin, and I'm guessing it's
missing something. The plugin is documented here:
http://confluence.atlassian.com/display/CONFEXT/Plugin+Developer+Kit+for+Maven2
and the source is here:
http://svn.atlassian.com/svn/public/contrib/maven-plugins/com.atlassian.maven.plugins/atlassian-pdk/trunk/
with FishEye monitoring here:
http://svn.atlassian.com/fisheye/browse/public/contrib/maven-plugins/com.atlassian.maven.plugins/atlassian-pdk/trunk/
If you have any specific questions I'd be more than happy to answer
them, however answering a send us more info is as useful to me as it
doesn't work is to you ;) Please, more questions!
I'm struggling to find concise documentation as everything is loosely
linked and the penny hasn't dropped yet as to what I'm missing.
Thanks,
Looking at your components.xml
(http://svn.atlassian.com/svn/public/contrib/maven-plugins/com.atlassian.maven.plugins/atlassian-pdk/trunk/src/main/resources/META-INF/plexus/components.xml),
this might explain why you can't deploy:
!--
Install and deploy don't really make sense for plugins.
--
install/
deploy/
Tom
ps: you can just attach the complete build output in a file rather than
copy/paste a part. The stack trace you sent is normal, and I still can't
see if Maven terminated with an error...
--
Dan Hardiker
Adaptavist.com Ltd
-
To unsubscribe, e-mail: [EMAIL
Re: Deployment in M2
It's a bit of hack, but you could set altDeploymentRepositorydulmmy::default::file://c:/temp/repo/altDeploymentRepository in the POMs of those projects. See http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#altDeploymentRepository Tom On Dec 23, 2007 9:08 AM, Morgovsky, Alexander (US - Glen Mills) [EMAIL PROTECTED] wrote: Hello. Is it possible to disable uploading to the shared Maven Repository during an M2 deployment? In my deployment, I have customized plugins bound to the deployment phase, and I need these to run, but I do not need the binaries to be deployed themselves. Thank you. This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1]
Re: How to mvn deploy artifacts with packagingatlassian-plugin/packaging
I'm assuming you have the source, and want to build and deploy it (opposed to having a binary and wanting do to a deploy-file). There should be a maven plugin that defines the atlassian-plugin packaging. This plugin would define a mapping from atlassian-plugin to a lifecycle (which defines which plugins are run) and an artifact type (which says that the extension is .jar). In order for these mappings to be picked up, you need to specify extensionstrue/extensions on that maven plugin. If that doesn't work, try sending us some more info than 'it doesn't work'. Some output (with -X), a pom, ... Tom On Dec 23, 2007 3:34 PM, Dan Hardiker [EMAIL PROTECTED] wrote: Hi, I have some artifacts which have packagingjar/packaging and some which have packagingatlassian-plugin/packaging, and I want to use mvn deploy to put them into my subversion-backed repository (I am using wagon-svn). The jar goes in fine, but the atlassian-plugin doesn't. To save questions, the atlassian-plugin packaging simply lays out the jar slightly differently (requiring an atlassian-plugin.xml, and adding in bundled dependencies into META-INF/lib or extracting them in an uber-jar fashion depending on settings). I've checked out the wagon source and greped it for both jar and packaging, neither of which got me far at all. I'm not even sure where this behaviour is defined and google is being uncharacteristically unhelpful. Any idea where I should be looking to configure the atlassian-plugin packaging to react the same in wagon as jar packaging? -- Dan Hardiker Adaptavist.com Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extends plugins
I usually just copy the source for the plugins I'm extending. They often are only wrappers around some reusable plexus component. Tom On Dec 21, 2007 11:03 AM, Benoit Decherf [EMAIL PROTECTED] wrote: Hi, I'm working on the migration of some projects from ant to maven. for some of the work done in ant target, there is no corresponding plugin for maven (ex: serialver: http://serialver.sourceforge.net/). So I make a plugin that comment the serialversionUID on the source class. Then the plugin compile the class and execute serialver to compute the serializeVerionUID and compare it to the last one. My problem is that to compile the generated sources, I need to extends the AbstractCompilerMojo from maven-compiler-plugin. But if i just extends this class, the parameter of the parent class are not set by plexus. How should I do this ? Thanks, Benoit PS: I'd like to distribute the plugins. Is there any repository where I can submit my sources ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 download possible?
Does this help you: http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html ? On Dec 20, 2007 7:50 PM, Andrew Robinson [EMAIL PROTECTED] wrote: I cannot use maven 2.0.8 due to blocker issue http://jira.codehaus.org/browse/MNG-2258. I am running on JDK 1.6 and have SQL plugin executions in my pom. Under JDK 1.6, they run out of order since the code uses Maps instead of lists or a linked list map. My code doesn't compile on JDK 1.5 and some of my build goals fail under JDK 1.6. So I am stuck without being able to use maven right now. Can MNG-2258 be back-ported for a 2.0.8.1 release, or will 2.1 be out soon (meaning in the next week or so)? If no to both of these questions, what is the best way to download, or at least produce a 2.1 snapshot release? I am able to build https://svn.apache.org/repos/asf/maven/components/trunk fine, but that does not give me a runnable mvn command. Is there a WIKI for making a 2.1 release that I missed? Thanks, Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version moving up fast
that only works for plugins, not for compile dependencies... I have the same problem, but I do my versioning slightly different. When I release my 1.0.0-SNAPSHOT, I'll make the release version 1.0.0.v20071126, and keep the development version at 1.0.0-SNAPSHOT... Tom On Nov 26, 2007 5:32 PM, EJ Ciramella [EMAIL PROTECTED] wrote: I don't remember exactly (and my list of mvn bookmarks aren't working as well as they used to), but my recollection is if you put nothing for version number, it depends on the metadata stored in your internal repository (as long as that is kept up to date). Or was there a way to say use the release version, again, relying on your metadata.xml file in your internal repository -Original Message- From: Borut Bolčina [mailto:[EMAIL PROTECTED] Sent: Monday, November 26, 2007 2:32 AM To: Maven Subject: Version moving up fast Hello maven users, if one of our in-house jars (lets call it A.jar) is progressing fast in terms of artifact version numbers (several times per week: 2.1 - 2.2 - 2.3- ... - 2.678 - 2.679 - ...), what is the best way for other artifacts which depend on this fast one to always use the last one? All the artifacts which depend on the A, would have to have their poms modified to 2.1-SNAPSHOT, 2.2-SNAPSHOT etc. because the SNAPSHOT version is in the trunk. This is error prone. I haven't looked into the release plugin yet, but I don't think it addresses this issue. One solution might be to name the A's version to something like 999-SNAPSHOT and then all the other jars would have their dependencies to this version. This smells like a dead fish in the sewer to me. What do you say? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting access to the versions in a POM
The mojo developer cookbook has part of this info. Feel free to add more...
http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook
Tom
On Nov 14, 2007 5:11 PM, Mark Russell [EMAIL PROTECTED] wrote:
Wayne:
Thanks That should get me started. I'll do some searching and then post back
any resources I find.
Wayne Fay wrote:
In your mojo, you'll need:
* @requiresDependencyResolution
* @requiresProject
And then:
/**
* iMaven Internal/i: Project to interact with.
*
* @parameter expression=${project}
* @required
* @readonly
*/
private MavenProject project;
Then you can navigate around in the MavenProject object to find the
dependencies and their versions etc. I assume this is on the web
somewhere but I'm not sure where, perhaps Wiki? Or Plugin Dev Center?
Wayne
On 11/14/07, Mark Russell [EMAIL PROTECTED] wrote:
I am writing an internal plugin for maven 2 for our company. One of the
things I need to do is to get access to the dependency
information that is configured in the pom. Is there a way to do that? I
have done several web searches but can not come up
with the correct string to get me an answer.
Please point me to a web page that will help me.
Thanks in advance :-
--
Mark Russell
Instantiations, Inc.
724-368-3331 (land line)
http://www.instantiations.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Russell
Instantiations, Inc.
724-368-3331 (land line)
http://www.instantiations.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Packaging type zip??
On 10/8/07, Yan Huang [EMAIL PROTECTED] wrote:
Hello,
I have these requirements to package a module:
- it's group ID is different from what I have at the top level
- no compilation or test is required
- it just needs to be packaged in zip format
- it needs to be deployed to a maven2 repository as part of deploy
phase
Do you think I need to separate this module out from the overall package
because of different group ID? If I need to build it separately, what's
going to be the packaging type? Maven does not support zip packaging
type though, and I don't want an empty jar being created in order to attach
zip file in the package phase by using assembly plugin.
Any thoughts or suggestions?
Thanks
Yan
Creating a plugin that provides a ZIP packaging is not that hard:
Use this mojo:
import java.io.File;
import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.project.MavenProject;
import org.apache.maven.project.MavenProjectHelper;
import org.codehaus.plexus.archiver.zip.ZipArchiver;
/**
* Creates a zip from the output directory, and sets it as the project artifact.
*
* @goal zip
* @phase package
* @requiresProject true
*/
public class ZipMojo extends AbstractMojo {
public static final String[] DEFAULT_EXCLUDES = {
// Miscellaneous typical temporary files
**/*~,
**/#*#,
**/.#*,
**/%*%,
**/._*,
// CVS
**/CVS,
**/CVS/**,
**/.cvsignore,
// SCCS
**/SCCS,
**/SCCS/**,
// Visual SourceSafe
**/vssver.scc,
// Subversion
**/.svn,
**/.svn/**,
// Arch/Bazaar
**/.arch-ids, **/.arch-ids/**,
// Mac
**/.DS_Store
};
private static final String[] DEFAULT_INCLUDES = new String[]{**/**};
/**
* Directory containing the generated ZIP.
*
* @parameter expression=${project.build.directory}
* @required
*/
private File outputDirectory;
/**
* Name of the generated ZIP.
*
* @parameter alias=zipName expression=${project.build.finalName}
* @required
*/
private String finalName;
/**
* The Jar archiver.
*
* @parameter
expression=${component.org.codehaus.plexus.archiver.Archiver#zip}
* @required
*/
private ZipArchiver zipArchiver;
/**
* The maven project.
*
* @parameter expression=${project}
* @required
* @readonly
*/
private MavenProject project;
/**
* @component
*/
private MavenProjectHelper projectHelper;
/**
* Whether creating the archive should be forced.
* @parameter expression=${jar.forceCreation} default-value=false
*/
private boolean forceCreation;
/**
* Directory containing the classes.
*
* @parameter expression=${project.build.outputDirectory}
* @required
*/
private File classesDirectory;
/**
* Classifier to add to the artifact generated. If given, the
artifact will be an attachment instead.
*
* @parameter
*/
private String classifier;
protected String getClassifier()
{
return classifier;
}
/**
* Return the main classes directory, so it's used as the root of the jar.
*/
protected File getClassesDirectory()
{
return classesDirectory;
}
protected final MavenProject getProject()
{
return project;
}
protected static File getZipFile( File basedir, String finalName,
String classifier )
{
if ( classifier == null )
{
classifier = ;
}
else if ( classifier.trim().length() 0
!classifier.startsWith( - ) )
{
classifier = - + classifier;
}
return new File( basedir, finalName + classifier + .zip );
}
/**
* Generates the ZIP.
*
* @todo Add license files in META-INF directory.
*/
public File createArchive()
throws MojoExecutionException
{
File zipFile = getZipFile( outputDirectory, finalName,
getClassifier() );
try
{
File contentDirectory = getClassesDirectory();
if ( !contentDirectory.exists() )
{
getLog().warn( ZIP will be empty - no content was
marked for inclusion! );
}
else
{
zipArchiver.addDirectory( contentDirectory,
DEFAULT_INCLUDES, DEFAULT_EXCLUDES );
}
zipArchiver.setForced(forceCreation);
zipArchiver.setDestFile(zipFile);
zipArchiver.createArchive();
return zipFile;
}
catch ( Exception e )
{
throw new MojoExecutionException( Error assembling ZIP, e );
}
}
/**
* Generates the ZIP.
*
* @todo Add license files in
alternative release plugin
Hi all, I have a lot of multi-module projects that I need to release in an automated way. To help me with that, I wrote an alternative release plugin based on the release-manager infrastructure; Features/Limitations: - svn only - no separate prepare/perform. POMs are modified locally, and if the release succeeds the local working copy is copied directly to a tag - atomic deployment. The build deploys to a local staging repository, and if the build succeeds, this repository is deployed to the remote repository. - alternative versioning strategy. Instead of releasing x.y.z-SNAPSHOT as x.y.z and updating to x.y.z+1-SNAPSHOT, I release as x.y.z.vDATE_TIME where DATE_TIME is the date/time of the last commit on the project. The development version is left unchanged. - release versions can be for the entire project or module-by-module I've attached the source to MOJO-903. If there is enough interest, I will add it to the mojo subversion repo. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Community review of the next commons-logging pom
This is the OSGi technical whitepaper: http://www.osgi.org/documents/collateral/OSGiTechnicalWhitePaper.pdf . Most relevant here is the Modularity section of the Architecture chapter. To be usable in an OSGi setting, the jar manifest needs to have some entries added. Most important are the name and version, and a list of packages that are provided and/or used by the plugin. The Apache Felix project has a maven-bundle-plugin that automates this process. More info here: http://cwiki.apache.org/confluence/display/FELIX/Maven+Bundle+Plugin+%28BND%29 One of the things you can also do with this plugin, is select which packages end up in your jar. Looking at the current POM, that might be useful. On 8/27/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi Tom I've heard the term OSGi from time to time, but have never took the time to learn more about it. Do you know of a good place where I can find out more about it? A quick look at Google suggests that it has something to do with entries in the manifest in the jar file, is that correct? What would they look like and what is the benefit for the community if we add them? Tom Huybrechts wrote: Is there any chance that OSGi headers could be added ? On 8/27/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi all The poms for commons logging has taken some beating on this list over the years. The reason for that has been the dependencies section. Previous poms of commons-logging was created for Maven 1. These were then converted into Maven 2 poms with various degree of success. In particular the scope wasn't set properly. We are now preparing the next release of commons-logging (version 1.1.1) which will be built with Maven 2. That means that the pom that ends up in the Maven 2 repository will be the same one that we have created. To make sure that we have covered all bases this time we invite you, the community, to help us get it right. The current pom.xml is available for your viewing in our subversion repository: https://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?revision=568979view=markup Please post any comments you have on the pom to this list, and I will bring the over to the commons community. -- Dennis Lundberg Apache Commons committer and PMC member - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Community review of the next commons-logging pom
Is there any chance that OSGi headers could be added ? On 8/27/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi all The poms for commons logging has taken some beating on this list over the years. The reason for that has been the dependencies section. Previous poms of commons-logging was created for Maven 1. These were then converted into Maven 2 poms with various degree of success. In particular the scope wasn't set properly. We are now preparing the next release of commons-logging (version 1.1.1) which will be built with Maven 2. That means that the pom that ends up in the Maven 2 repository will be the same one that we have created. To make sure that we have covered all bases this time we invite you, the community, to help us get it right. The current pom.xml is available for your viewing in our subversion repository: https://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?revision=568979view=markup Please post any comments you have on the pom to this list, and I will bring the over to the commons community. -- Dennis Lundberg Apache Commons committer and PMC member - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: webdav
I guess that isn't possible for deploy:deploy-file ? On 8/20/07, Eric Redmond [EMAIL PROTECTED] wrote: You have to add an extension block in your POM to use webdav. http://maven.apache.org/guides/mini/guide-using-extensions.html -- Eric Redmond http://blog.propellors.net On 8/20/07, Borut Bolčina [EMAIL PROTECTED] wrote: Hello, why are not all the neccesary jars included in 2.0.7 to support deployment with web-dav? Regards, Borut
Re: Can't compile
On 8/16/07, Wayne Fay [EMAIL PROTECTED] wrote: Try mvn compile. The name of the plugin is compiler. The method you're executing is named compile. So the long way would be mvn compiler:compile. Note the r in the first one. But mvn compile is a short-cut. It's not really a shortcut (they are not identical) 'mvn compiler:compile executes one goal in the compiler plugin. 'mvn compile' executes all the phases in your lifecycle up to compile. So that would include generating sources, resources etc. The compiler:compile goal is included in the compile phase. Unless you know what you're doing, better use 'mvn compile... Tom Wayne On 8/16/07, Mathias P.W Nilsson [EMAIL PROTECTED] wrote: Ok this is very strange. I can't use mvn compile. I've tried it all. Delete all files in respository and try again. I then tried the mvn -e compile:compile and got the following error The plugin 'org.apache.maven.plugins:maven-compile-plugin' does not exist or no valid version could be found When I look in my respository the folder only contains a xml. I tried to download the maven-compile-plugin but i doesn't exist. It's only the maven-compiler-plugin notice the COMPILER and not COMPILE why is compile used? Why is it trying to download compile when I have sat compiler. Look at this POM file I'm near crying here. project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdse.digitalsupport.ftc/groupId artifactIdFTC/artifactId packagingjar/packaging version1.0-SNAPSHOT/version nameFTC/name urlhttp://maven.apache.org/url dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scoperuntime/scope /dependency dependency groupIdorg.hibernate/groupId artifactIdhibernate/artifactId version3.2.5.ga/version scoperuntime/scope /dependency dependency groupIdorg.hibernate/groupId artifactIdhibernate-annotations/artifactId version3.3.0.ga/version scoperuntime/scope /dependency dependency groupIdorg.hibernate/groupId artifactIdhibernate-entitymanager/artifactId version3.3.1.ga/version scoperuntime/scope /dependency dependency groupIdjboss/groupId artifactIdjboss-common-core/artifactId version2.2.0.GA/version scoperuntime/scope /dependency dependency groupIdorg.hibernate/groupId artifactIdhibernate-commons-annotations/artifactId version3.3.0.ga/version scoperuntime/scope /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version5.0.5/version scoperuntime/scope /dependency dependency groupIdc3p0/groupId artifactIdc3p0/artifactId version0.9.0/version scoperuntime/scope /dependency /dependencies build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target /configuration /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdhibernate3-maven-plugin/artifactId version2.0-alpha-2/version configuration executions execution phasegenerate-sources/phase goals goalhbm2ddl/goal /goals /execution /executions components component namehbm2ddl/name implementationannotationconfiguration/implementation /component component namehbm2hbmxml/name outputDirectorysrc/main/resources/outputDirectory /component /components componentProperties droptrue/drop
Re: [m2] release process - maven-release-plugin usage
You can use the release plugin on a multi-module project, and it will it walk the module graph for you. You can also run release:prepare with -B (batch mode) so that all defaults will be used automatically. On 7/30/07, James Abley [EMAIL PROTECTED] wrote: Hi, We currently have the following process for our releases: Walk the DAG of our modules in a breadth-first traversal [1] and for each module being released: 1) Create a branch in Subversion. 2) Check out the branch 3) Update the POMs so that no SNAPSHOT dependencies are stil in the POMs and commit these updates in the branch. 4) mvn release:prepare -D... 5) mvn release:perform 6) Update the POMs to reference the new SNAPSHOT dependency versions and commit these updates in the branch. 7) Merge the updated POMs back into main trunk. We have some Python scripts to do steps 1-3 and 6,7. Unfortunately step 4 doesn't seem to be possible to fully script due to prompting for release numbers and next development numbers. We could do more work with the reading and writing of child stdin / stdout, but I think it would be preferable for the release plugin to support being invoked in an enabling manner which assumes that we know what we are doing and just to use the defaults. I also noticed that the maven-release-plugin has had some changes in the last few months, with a new release:branch goal. And from a brief look at the plugin code, the logic is in place to do steps 3 and 6 within the plugin, but it doesn't appear to be exposed. I would like to be able to move to an all Maven solution. 1. Does this look possible, given the process that we have? And is it possible using the current release plugin, if invoked correctly, or would it require changes to expose the desired functionality? Please provide any examples of how you think this should work. 2. If I'm correct and the prepare step can't be automated, does anyone think this is a reasonable idea? If so, I'll raise a JIRA issue and look at whether I can provide a patch. Regards, James [1] http://en.wikipedia.org/wiki/Breadth-first_search - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: google-testar with Maven
It would be even more interesting if they actually had source code. On 7/22/07, Martin Villalobos [EMAIL PROTECTED] wrote: Hi Dmitry, take you a look about http://code.google.com/p/google-testar/. It Sound very interesting, but if I could integrate it with Maven, it could be much better. Cheers Martin. Dmitry wrote: div class=moz-text-flowed style=font-family: -moz-fixedhey, never used before testart. what the purposes of it? thanks, DM www.ejinz.com - Original Message - From: Martin Alejandro Villalobos [EMAIL PROTECTED] To: users@maven.apache.org Sent: Friday, July 20, 2007 2:31 PM Subject: google-testar with Maven Hello. Somebody knows if is possible integrate google-testar with Maven? Thanks. MArtin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] /div - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: google-testar with Maven
There they are... I was looking at the google-code downloads and svn. On 7/22/07, Wayne Fay [EMAIL PROTECTED] wrote: Unless I'm confused, both the binaries and source code are available: http://sourceforge.net/project/showfiles.php?group_id=175837package_id=201991 Wayne On 7/22/07, Tom Huybrechts [EMAIL PROTECTED] wrote: It would be even more interesting if they actually had source code. On 7/22/07, Martin Villalobos [EMAIL PROTECTED] wrote: Hi Dmitry, take you a look about http://code.google.com/p/google-testar/. It Sound very interesting, but if I could integrate it with Maven, it could be much better. Cheers Martin. Dmitry wrote: div class=moz-text-flowed style=font-family: -moz-fixedhey, never used before testart. what the purposes of it? thanks, DM www.ejinz.com - Original Message - From: Martin Alejandro Villalobos [EMAIL PROTECTED] To: users@maven.apache.org Sent: Friday, July 20, 2007 2:31 PM Subject: google-testar with Maven Hello. Somebody knows if is possible integrate google-testar with Maven? Thanks. MArtin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] /div - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inteference between multiple plugins with extensions
I've had a problem using different extension plugins that contribute a lifecycle in one multi-module project. My workaround has been to copy the contents of the components.xml for each lifecycle I need into a single separate maven-lifecycle-plugin. I only specify this plugin as an extension, and that fixes it for me. If you have the same packaging name mapped several times, you might need to give it different names. Tom On 6/12/07, Peter Nilsson [EMAIL PROTECTED] wrote: Hi, We are using Maven 2.0.6 to build both Java, C++ and C#. C++ is built with the help of maven-native-plugin and C# with NMaven. Our project tree has the following structure: Top Cpp Project_A Project_B CS Project_C Project_D The problem we encounter is that while C# and C++ builds work fine on their own it will fail if the same build command tries to build both C++ and C#. Ie, running mvn install in project Cpp or CS works but not doing it in project Top. One hypothesis we have is that the components.xml files in the maven-native-plugin and NMaven plugins map the same packaging but to different goals and for some reason these mappings interfere with each other even though the plugins are not being used in the same project. Project_A and Project_B in the example above only use the maven-native-plugin while Project_C and Project_D only use NMaven plugins. Can anybody confirm that the declared lifecycle mappings (in components.xml) for one plugin can have effect outside of the projects where this plugin is being used? If this is the case, is this a known bug? Is there any workaround? TIA, Peter This e-mail is confidential and may contain legally privileged information. It is intended only for the addressees. If you have received this e-mail in error, kindly notify us immediately by telephone or e-mail and delete the message from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-eclipse-plugin and PDE: do dependencies work?
On 6/11/07, Graham Leggett [EMAIL PROTECTED] wrote: On Mon, June 11, 2007 5:45 pm, Adrian Herscu wrote: I have a similar problem... Added a dependency to my PDE project run mvn eclipse:clean eclipse:eclipse and only the .project file is generated (without those linkedResources!). The .classpath file is not generated at all!!! Moreover, running mvn install on the project fails because the dependency is not in the classpath :-( This is a separate problem, fixed in http://jira.codehaus.org/browse/MECLIPSE-279. I am trying to get the maven-eclipse-plugin to a state where it a) works and is b) documented, but this is turning out to be a bit of a nightmare. Regards, Graham -- Generating PDE projects is much different from ordinary projects. PDE handles the classpath and interproject dependencies itself. Maven should never generate these, and certainly not try to link to a jar in the local repository. For external dependencies, you should think about setting up a target platform. There are a number of Maven plugins to be found to build PDE-based projects with Maven, and to create a target platform. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
batch release of a set of projects without using the default versioning scheme
I just spend some time examining the latest release plugin release. I'm trying to set up an automatic release from Cruisecontrol, and I want to specify the project versions myself, without relying on the automatic versioning. I found a way to do this, and I thought I'd share how... First, create a release.properties file yourself (I use ant), with the following content project.rel.groupId\:artifactId=release-version project.dev.groupId\:artifactId=new-development-version-SNAPSHOT Next, run your release mvn -B release:prepare release:perform -Dresume=true -DautoVersionSubmodules=true -B: batch mode -Dresume=true normally resumes a interrupted release, but in this case it just reads the defaults from the release.properties file. -DautoVersionSubModules=true uses the same version for each submodule as for the parent If you don't want the same version for each project, you can specify a version per project in the release.properties file and skip the autoVersionSubModules. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven release plugin question
just add the plugin with the version you want to the plugin management section of your pom On 6/11/07, srinivas ramgopal [EMAIL PROTECTED] wrote: Hi all, Current latest version of maven release plugin from ibiblio has errors. As a workaround, I want to force maven to use the older(the version before the latest one)version of this plugin. This plugin related information is not part of my pom file as it is used by Maven automatically. Given this, how and where do I specify to maven to use a particular version of this plugin? Your input is higly appreciated. Thanks in advance. -- View this message in context: http://www.nabble.com/maven-release-plugin-question-tf3903737s177.html#a11067768 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] where to put gen-src so it will get compiles and packaged...???
Or use the build-helper plugin
http://mojo.codehaus.org/build-helper-maven-plugin/howto.html
On 6/8/07, Wayne Fay [EMAIL PROTECTED] wrote:
You should make a real plugin. Its really simple. Then you can use
the add source root bit.
Wayne
On 6/8/07, Mick Knutson [EMAIL PROTECTED] wrote:
But all I am doing is calling Oracle's genInterface via a bat file
On 6/8/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 8 Jun 07, at 5:02 PM 8 Jun 07, Mick Knutson wrote:
Well, I added the source to ./target/generated-sources/*
Look at the example I showed you. This will not work and is not
recommended. Your plugin that generates the sources must use the
reference of the MavenProject and add the resources and sources
programmatically. You do not want to make everyone using your plugin
have to configure this. Look at the Antlr plugin, which is the way
you should be doing it.
With adding the includes to my compiler like this:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
compilerVersion1.5/compilerVersion
source1.5/source
target1.5/target
debug${compiler.debug}/debug
showDeprecation${showDeprecation}/
showDeprecation
showWarnings${showWarnings}/showWarnings
optimize${optimize}/optimize
meminitial${meminitial}/meminitial
maxmem${maxmem}/maxmem
includes
include${basedir}/src/main/java/include
include${basedir}/src/test/java/include
include${basedir}/target/generated-sources/include
/includes
/configuration
/plugin
I start getting test compilation errors.
On 6/8/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 8 Jun 07, at 4:27 PM 8 Jun 07, Mick Knutson wrote:
I have java and xml files being generated and I want to know where
to put
them in order for them to be compiled and included into my war?
It's not where you put, but telling Maven there are new sources and
new resources:
From the Antlr plugin:
if ( project != null )
{
// Add resources
projectHelper.addResource( project,
outputDirectory.getAbsolutePath(), Collections
.singletonList( **/**.txt ), new ArrayList() );
// Add source root
project.addCompileSourceRoot
( outputDirectory.getAbsolutePath()
);
}
Reference: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-
antlr-plugin/src/main/java/org/apache/maven/plugin/antlr/
AbstractAntlrMojo.java
Typically you put generated sources in ${project.build.directory}/
generated-sources/short-plugin-id
So for the Antlr plugin this is target/generated-sources/antlr
--
---
Thanks,
Mick Knutson
http://www.baselogic.com
http://www.blincmagazine.com
http://www.djmick.com
http://www.myspace.com/mickknutson
http://www.myspace.com/djmick_dot_com
http://www.myspace.com/sexybeotches
http://www.thumpradio.com
---
Thanks,
Jason
--
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
---
Thanks,
Mick Knutson
http://www.baselogic.com
http://www.blincmagazine.com
http://www.djmick.com
http://www.myspace.com/mickknutson
http://www.myspace.com/djmick_dot_com
http://www.myspace.com/sexybeotches
http://www.thumpradio.com
---
Thanks,
Jason
--
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
---
Thanks,
Mick Knutson
http://www.baselogic.com
http://www.blincmagazine.com
http://www.djmick.com
http://www.myspace.com/mickknutson
http://www.myspace.com/djmick_dot_com
http://www.myspace.com/sexybeotches
http://www.thumpradio.com
---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: release and deploy plugins
release:prepare will update the old snapshot version to the release version, make a tag and then update the release version to the new snapshot version. release:perform checks out the tag under the target/checkout directory and does a deploy from there. On 6/3/07, Nathan Coast [EMAIL PROTECTED] wrote: Hi, apologies if this is a bit of a newbie question... how are the release and deploy plugins supposed to work together? I have successfully executed mvn release:prepare and mvn release:perform however when I come to execute mvn deploy, the version has been incremented to NEXT_VERSION-SNAPSHOT so rather than deploying my release version, maven deploys the snapshot jar. the pom.xml only contains the 1.3 version for a brief instant during release:prepare - obviously I'm doing something wrong :) thanks, Nathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JUnit4 test cases using @Before, @After fail test?
would you mind sharing some more information ? POMs, exceptions, test source, -X output ? As a general remark: make sure you have the latest surefire plugin... Tom On 5/23/07, Alexander Sack [EMAIL PROTECTED] wrote: Hey folks, is this a known issue that if I use @Before it will fail my test? I searched some of the archives and saw some threads go by about this. Is this still an issue? Thanks! -aps -- What lies behind us and what lies in front of us is of little concern to what lies within us. -Ralph Waldo Emerson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse RCP/PDE building and Maven
On 5/14/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 5 May 07, at 6:28 PM 5 May 07, Carlos Sanchez wrote: I think we need an Eclipse section in the wiki and put all the pages under that Also another thing I wanted to do is cleanup the maven eclipse plugin, deprecate all OSGi stuff in favor of the Felix bundle plugin, I don't know about that. We have two completely, and fully functional options that have been in production for quite sometime while I doubt there is much production use of the Felix plugin. We have the code donated by PrincetonSoftech which is very well documented in this article here: http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and- Maven2/index.html And the code for this project is here: http://svn.codehaus.org/m2eclipse/maven-pst/ And we have Tom's work which is being used in a very large organization and has been working well for quite some time: http://svn.codehaus.org/m2eclipse/tycho/trunk/ The first solution is targeted at plugins, but the second is more general with it's own lifecycle and set of plugins. and improve the Eclipse plugins to Maven repository conversion, so we can run it as soon as a new version of eclipse goes out. This is something I've discussed with Eugene, but what about treating an Eclipse installation as another local repository. If you are developing Eclipse plugins against a particular version of Eclipse then you're going to have the installation present. This might make it easier then trying to scrape out a local repository and convert it which is what the two solutions do above. Not sure what other solutions do but this seems less then optimal. Probably makes sense to just use the Eclipse installation in its current form instead of duplicating it. From the point of view of repeatable builds, I want to build against a fixed and shared repository instead of any random Eclipse install. Based on the OSGi manifest, you can pick the right dependency in any Eclipse install, but these dependencies are typically very loose. Not like the Maven dependencies where all dependencies refer to a fixed artifacts. That said, this is a cool feature if you just need ease of use and quick configuration. You wouldn't even need to specify POM dependencies any more, just a link to an eclipse install where your dependencies should come from... Tom One of the things to change is the use of artifactIds and groupIds, i think we should make the convention of using groupId.artifactId for all those deployments that use only a folder, like the eclipse plugins directory, WEB-INF/lib in a war,... That seems fine at first blush but I would like to work completely through the problem. I don't think having JARs named differently based on where they are is such a great idea. Though I agree with the new naming convention. other interesting thing i heard about was the possibility of using an extension in eclipse to access a maven repository as an update site. That's cool, where was that? Jeff McAffer talked about a long time ago just wondering if he went anywhere with that. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous
Don't forget you use a lot more plugins than you think. Who specifies versions for resources; compiler, surefire, install, deploy, clean, ... ? Maybe we need a plugin that can rewrite your POMs to specify versions for all the plugins that are used ? Tom On 4/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: I agree, automatic resolution of plugin versions is dangerous and you must use versions if you want reproducible builds. it's easy to add them to your parent pom in the pluginManagement section On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Hi everyone, I wanted to send out a quick email to let everyone know about some discussion that's been taking place on the developers' list regarding plugin versions. In trying to release the 2.2-beta-1 version of the assembly plugin, it became apparent that this version fixes some bugs in the 2.1version that don't necessarily look like bugs. All discussion about what is or is not a bug aside, the discussion raises an interesting point: if you do not specify a version for the plugins in your POMs, a situation can arise where Maven will seamlessly resolve an incompatible plugin version and try to use it. Here's an example: Say I create a project that uses the assembly plugin, version 2.1. My assembly descriptor takes advantage of a bug in this version where the explicit inclusion of a .tar.gz dependency does not have its own transitive dependencies included, unless they too are explicitly included. This is incorrect, because there is no ArtifactHandler that specifies that the .tar.gz file contains its own dependencies (so, therefore, should not have its transitive dependencies resolved, much less factored into inclusion/exclusion)...also, from a semantics point of view, Maven's other dependency usages indicate that specifying a dependency implies that you're specifying that dependency's transitive dependencies...the whole sub-graph should be handled, in other words. Having created this project with its assembly descriptor, but WITHOUT A VERSION IN THE ASSEMBLY PLUGIN DECLARATION, I commit my project. Now, some time later, after the next version of the assembly plugin fixes this bug, a user comes along. He installs Maven, checks out my project, and tries to build. Without a single line of code changing in my project, the build fails, because his Maven instance resolved the plugin to the newer version. I cannot replicate his failed build, because my assembly-plugin version had not been updated (I didn't use -U during the build). You can say that the next version should make an effort to support users exploiting bugs like this, and you can say that plugins need to deprecate and gradually move away from behavior that has turned out to be bad design, counter-intuitive, etc. To this extent, you could argue that the next release that fixed the bug above should have made an allowance for this scenario. However, consider what happens if the plugin has been released several times...say that the newest version is actually 3.1 now. In this scenario, it's entirely reasonable to think that the developers have provided a long migration period - along with deprecation warnings - that spanned multiple versions, and then finally dropped the support for this broken configuration. However, Maven has no idea of any of this, and the aforementioned setup will break. All of this can be avoided by simply being careful about evaluating, then migrating, to new plugin versions in a very deliberate fashion. If you take a look at the world of systems administration, you see this sort of thing everywhere. People take enough time to pour over release notes and determine whether the new version is likely to wreck the existing setup. The same should go for building a reproducible build infrastructure. I'm going to start a discussion on the developers' for getting rid of the plugin-version auto-resolver in Maven 2.1 immediately, to start pushing the tools down this path. However, it will make everyone's lives easier to start the process now. Please, take a moment and put the plugin versions into your POMs. Thanks, John -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous
Two more ideas: - Versioned lifecycles. Let a version of a lifecycle map to versions of each of its plugins. Allow users to override these by specifying explicit versions for the plugins. If you don't specify a version for the packaging, you get the old behaviour. - Have the maven-release-plugin add versions for all plugins, so you would at least have reproduciblity for releases. There must be a JIRA for this already, but I couldn't find it. Tom On 4/11/07, John Casey [EMAIL PROTECTED] wrote: I think that sort of plugin would be a great idea. For the plugins in the standard packaging lifecycles (to which you're referring, I believe), I still think that Maven should force you to supply a version for each one. It might make sense to have a version-set dependency or artifact that you can use to specify them as a group, so you have a sort of standardized toolchain for your build. This is possible via parent POM and pluginManagement today, but it is sort of orthogonal to normal inheritance in some ways, too... -john On 4/11/07, Tom Huybrechts [EMAIL PROTECTED] wrote: Don't forget you use a lot more plugins than you think. Who specifies versions for resources; compiler, surefire, install, deploy, clean, ... ? Maybe we need a plugin that can rewrite your POMs to specify versions for all the plugins that are used ? Tom On 4/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: I agree, automatic resolution of plugin versions is dangerous and you must use versions if you want reproducible builds. it's easy to add them to your parent pom in the pluginManagement section On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Hi everyone, I wanted to send out a quick email to let everyone know about some discussion that's been taking place on the developers' list regarding plugin versions. In trying to release the 2.2-beta-1 version of the assembly plugin, it became apparent that this version fixes some bugs in the 2.1version that don't necessarily look like bugs. All discussion about what is or is not a bug aside, the discussion raises an interesting point: if you do not specify a version for the plugins in your POMs, a situation can arise where Maven will seamlessly resolve an incompatible plugin version and try to use it. Here's an example: Say I create a project that uses the assembly plugin, version 2.1. My assembly descriptor takes advantage of a bug in this version where the explicit inclusion of a .tar.gz dependency does not have its own transitive dependencies included, unless they too are explicitly included. This is incorrect, because there is no ArtifactHandler that specifies that the .tar.gz file contains its own dependencies (so, therefore, should not have its transitive dependencies resolved, much less factored into inclusion/exclusion)...also, from a semantics point of view, Maven's other dependency usages indicate that specifying a dependency implies that you're specifying that dependency's transitive dependencies...the whole sub-graph should be handled, in other words. Having created this project with its assembly descriptor, but WITHOUT A VERSION IN THE ASSEMBLY PLUGIN DECLARATION, I commit my project. Now, some time later, after the next version of the assembly plugin fixes this bug, a user comes along. He installs Maven, checks out my project, and tries to build. Without a single line of code changing in my project, the build fails, because his Maven instance resolved the plugin to the newer version. I cannot replicate his failed build, because my assembly-plugin version had not been updated (I didn't use -U during the build). You can say that the next version should make an effort to support users exploiting bugs like this, and you can say that plugins need to deprecate and gradually move away from behavior that has turned out to be bad design, counter-intuitive, etc. To this extent, you could argue that the next release that fixed the bug above should have made an allowance for this scenario. However, consider what happens if the plugin has been released several times...say that the newest version is actually 3.1 now. In this scenario, it's entirely reasonable to think that the developers have provided a long migration period - along with deprecation warnings - that spanned multiple versions, and then finally dropped the support for this broken configuration. However, Maven has no idea of any of this, and the aforementioned setup will break. All of this can be avoided by simply being careful about evaluating, then migrating, to new plugin versions in a very deliberate fashion. If you take a look at the world of systems administration, you see this sort of thing everywhere. People take enough time to pour over release notes and determine whether the new version is likely to wreck
Re: Eclipse RCP/PDE building and Maven
it's almost undocumented, and there are bugs, but this works for me: https://svn.codehaus.org/m2eclipse/tycho/trunk/ Tom On 3/28/07, Barrie Treloar [EMAIL PROTECTED] wrote: I was trawling through the archives to see if there was a better way of building Eclipse RCP plugins via Maven and noticed the following: http://www.nabble.com/forum/ViewPost.jtp?post=3560407framed=yskin=177 (almost a year ago) and http://www.nabble.com/forum/ViewPost.jtp?post=933004framed=yskin=177 I've unetiquettely pinged the main people I could find doing a trawl and hopefully they can pass on to others. I'd like help make this a reality but would like to make sure that there was a single focus for this work. Has any progress been made about getting people together and sorting this out? Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Passing args to release:prepare
Like I said, it's a very simple patch. I use it because I want to
release a big multi-module project with the same (non-default) version
for all modules.
tom
On 3/26/07, Jorg Heymans [EMAIL PROTECTED] wrote:
I haven't tried this patch, but it looks like you're setting the information
once for all artifacts in the release process ? How would this work in a
multi-module release with different version numbers ?
I'm big +1 though on the idea of being able to run through release:prepare
without user intervention, either through POM configuration or system
variables.
Jorg
On 3/25/07, Tom Huybrechts [EMAIL PROTECTED] wrote:
I have a very simple patch for the release-manager from trunk. It
let's you specify defaults for the release version and the new
version. Combined with -B you can completely automate your release.
These are the properties you need to set:
-Dmaven.release.version=the release version
-Dmaven.release.new=the new development version
start of patch
Index:
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/MapVersionsPhase.java
===
---
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/MapVersionsPhase.java
(revision
519038)
+++
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/MapVersionsPhase.java
(working
copy)
@@ -96,7 +96,7 @@
String nextVersion = null;
if ( version != null )
{
-nextVersion =
version.getNextVersion().getSnapshotVersionString();
+nextVersion =
System.getProperty(maven.release.new,
version.getNextVersion().getSnapshotVersionString());
}
if ( releaseDescriptor.isInteractive() )
@@ -120,8 +120,9 @@
String nextVersion = null;
if ( version != null )
{
-nextVersion = version.getReleaseVersionString();
+ nextVersion =
System.getProperty(maven.release.version,
version.getReleaseVersionString());
}
+
if ( releaseDescriptor.isInteractive() )
{
end of patch
On 3/25/07, Dan Tran [EMAIL PROTECTED] wrote:
pass in -B, maven will use it own default values. Dont think you can
overide the default value
-D
On 3/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
When running release:prepare, Maven stops and asks for user input to
define the release number for each module, the SCM tag to be used and
then
the new release number for each module.
Is there a way to run release:prepare and pass all of that information
on
the command line or through a properties file so that I can get
release:prepare to run all the way through with no human interaction
being
necessary?
Thanks.
--
Craig Dickson
Software Engineering Manager
Behr Process Corporation
Santa Ana, California
---
The information contained in this e-mail message may be proprietary,
privileged, confidential or protected from disclosure. If you are not
the
intended recipient, any dissemination, distribution or copying is
strictly
prohibited. If you think that you have received this e-mail message in
error, please e-mail the sender.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Passing args to release:prepare
I have a very simple patch for the release-manager from trunk. It
let's you specify defaults for the release version and the new
version. Combined with -B you can completely automate your release.
These are the properties you need to set:
-Dmaven.release.version=the release version
-Dmaven.release.new=the new development version
start of patch
Index:
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/MapVersionsPhase.java
===
---
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/MapVersionsPhase.java
(revision
519038)
+++
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/MapVersionsPhase.java
(working
copy)
@@ -96,7 +96,7 @@
String nextVersion = null;
if ( version != null )
{
-nextVersion =
version.getNextVersion().getSnapshotVersionString();
+nextVersion =
System.getProperty(maven.release.new,
version.getNextVersion().getSnapshotVersionString());
}
if ( releaseDescriptor.isInteractive() )
@@ -120,8 +120,9 @@
String nextVersion = null;
if ( version != null )
{
-nextVersion = version.getReleaseVersionString();
+ nextVersion =
System.getProperty(maven.release.version,
version.getReleaseVersionString());
}
+
if ( releaseDescriptor.isInteractive() )
{
end of patch
On 3/25/07, Dan Tran [EMAIL PROTECTED] wrote:
pass in -B, maven will use it own default values. Dont think you can
overide the default value
-D
On 3/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
When running release:prepare, Maven stops and asks for user input to
define the release number for each module, the SCM tag to be used and then
the new release number for each module.
Is there a way to run release:prepare and pass all of that information on
the command line or through a properties file so that I can get
release:prepare to run all the way through with no human interaction being
necessary?
Thanks.
--
Craig Dickson
Software Engineering Manager
Behr Process Corporation
Santa Ana, California
---
The information contained in this e-mail message may be proprietary,
privileged, confidential or protected from disclosure. If you are not the
intended recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this e-mail message in
error, please e-mail the sender.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 and JUnit4
Are you sure you are using the latest surefire ?
Can you run with -X ?
Tom
On 3/20/07, Marcos Silva Pereira [EMAIL PROTECTED] wrote:
Ok, I now that this is a so much frequent question, but I can't find a neat
thread about this issue. I already have take a look at surefire plugin doc
and JIRA without success. In surefire how
tohttp://maven.apache.org/plugins/maven-surefire-plugin/howto.htmlyou
can see this statement:
Which providers are available is controlled simply by the inclusion of the
appropriate dependencies (ie, junit:junit for JUnit, org.testng:testng
4.7+for TestNG). Since this is required to compile the test classes
anyway, no
additional configuration is required.
JUnit 4 is configured in the following way:
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.2/version
scopetest/scope
/dependency
But I catch some test failures when my tests except some exception:
@Test(expected = IllegalStateException.class)
public final void testSomethingBah() throws Exception {
...
}
So, how I can configure Maven/Surefire to correctly run JUnit 4 tests?
Kind Regards,
--
Marcos Silva Pereira
recife - pe
[EMAIL PROTECTED]
skype: marcos.silva.pereira
http://blastemica.blogspot.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the simplest way to populate a remote depot?
Read That Fine Manual : http://maven.apache.org/plugins/maven-deploy-plugin/file-deployment.html On 3/3/07, Christian Goetze [EMAIL PROTECTED] wrote: I have some third party jars and want to place them in our common remote repo. I've been placing them there, writing their pom file and doing the sha1sum by hand. Is there some kind of deploy target for this which would make it easier? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I just don't understand
http://maven.apache.org/plugins/maven-clean-plugin/examples/delete_additional_files.html
I don't see why this wouldn't work for absolute paths.
On 2/21/07, EJ Ciramella [EMAIL PROTECTED] wrote:
If no one has a fix for this, how does one delete a directory created
outside of the working directory?
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 20, 2007 6:18 PM
To: Maven Users List
Subject: RE: I just don't understand
Hmmm - I'm running mvn clean yet it tries to download snap shot type
dependencies that wouldn't be available.
This is a bug in the antrun plugin I think:
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idassembler/id
phasepackage/phase
configuration
tasks
ant antfile=build.xml target=package.war
property name=jboss.home value=${jboss.home} /
property name=work.dir value=${work.dir} /
property name=assembler.standalone
value=${assembler.standalone}/
property name=atg.home value=${atg.home} /
property name=project.build.directory
value=${project.build.directory} /
!-- TODO: Is there a built-in maven property for the
source directory? --
property name=project.source.directory
value=${work.dir}/frontoffice/caApp/src /
property name=project.compileClasspathElements
value=${project.compileClasspathElements} /
property name=m2.repo value=${m2.repo} /
/ant
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
!--
execution
idantclean/id
phaseclean/phase
configuration
tasks
ant antfile=build.xml target=clean
property name=atg.home value=${atg.home} /
/ant
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
--
/executions
/plugin
With the second one commented out, I'm fine. When it's uncommented,
maven tries to go get the dependencies - someone please help here...
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 20, 2007 5:30 PM
To: Maven Users List
Subject: Re: I just don't understand
You might not like it, but the first phase of any Maven build is
validate. According to the documentation, this phase is responsible
to validate the project is correct and all necessary information is
available.
The primary thing validated is that any artifacts required during a
later phase of the lifecycle are available, and if not, those
artifacts are first acquired. If they cannot be acquired, then Maven
will exit with the failure you have seen.
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycl
e.html
Wayne
On 2/20/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote:
You can use maven in offline mode if you don't want it to connect to
the
internet to fetch or update a dependency, just use -o parameter,
otherwise
maven will try and connect to the internet to update snapshots as
often as
specified in your snapshots update policy.
Bashar
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 20, 2007 2:44 PM
To: Maven Users List
Subject: I just don't understand
When you do something like mvn clean why would it try to download
compile time dependencies?
We have something like this:
dependencies
dependency
groupIdlty/groupId
artifactIdlty-model/artifactId
version1.0-SNAPSHOT/version
/dependency
dependency
groupIdlty/groupId
artifactIdlty-utils/artifactId
version1.0-SNAPSHOT/version
/dependency
dependency
groupIdlty/groupId
artifactIdcrypto/artifactId
version1.0-SNAPSHOT/version
/dependency
dependency
groupIdcommons-lang/groupId
artifactIdcommons-lang/artifactId
version2.1/version
/dependency
...
Yet when I do a maven clean, I see:
[INFO] [cobertura:clean {execution: default}]
[WARNING]
Artifact atg:das-classes:jar:2006.3.P2:provided retains local
scope 'provided' overriding broader scope 'compile'
given by a dependency. If this is not intended, modify or
remove
the local scope.
Downloading:
file:\\build.corp.upromise.com/maven2/lty/lty-model/1.0-SNAPSHOT/lty-mod
el-1.0-SNAPSHOT.jar
file:///\\build.corp.upromise.com/maven2/lty/lty-model/1.0-SNAPSHOT/lty
-model-1.0-SNAPSHOT.jar
[WARNING] Unable to get resource from repository central
(file:\\build.corp.upromise.com/maven2
file:///\\build.corp.upromise.com/maven2 )
Downloading:
file:\\build.corp.upromise.com/maven2/lty/crypto/1.0-SNAPSHOT/crypto-1.0
-SNAPSHOT.jar
Re: Getting JAR for current plugin
IIRC, getClass().getProtectionDomain().getCodeSource().getLocation()
will return the URL off the jar containing the current class. Maybe
that helps ?
Tom
On 2/18/07, Howard Lewis Ship [EMAIL PROTECTED] wrote:
I'm using javadoc to scrape a set of classes and annotations to form
an XML file that, in turn, will generate some Doxia documentation as
part of my site.
I'm copying a lot of stuff from maven-javadoc-plugin.
Here's my issue: I need to run Javadoc against a doclet defined
within the plugin.
Therefore, I need to set the -docletpath argument on the javadoc command line.
I haven't found a way to get this to work ideally. What I have seems
to work for the moment:
/**
* Needed to help locate this plugin's local JAR file for the
-doclet argument.
*
* @parameter default-value=${localRepository}
* @read-only
*/
private ArtifactRepository localRepository;
/**
* Needed to help locate this plugin's local JAR file for the
-doclet argument.
*
* @parameter default-value=${plugin.groupId}
* @read-only
*/
private String pluginGroupId;
/**
* Needed to help locate this plugin's local JAR file for the
-doclet argument.
*
* @parameter default-value=${plugin.artifactId}
* @read-only
*/
private String pluginArtifactId;
/**
* Needed to help locate this plugin's local JAR file for the
-doclet argument.
*
* @parameter default-value=${plugin.version}
* @read-only
*/
private String pluginVersion;
@SuppressWarnings(unchecked)
private String docletPath() throws MavenReportException
{
File file = new File(localRepository.getBasedir());
for (String term : pluginGroupId.split(\\.))
file = new File(file, term);
file = new File(file, pluginArtifactId);
file = new File(file, pluginVersion);
file = new File(file, String.format(%s-%s.jar,
pluginArtifactId, pluginVersion));
return file.getAbsolutePath();
}
Notes:
I was unable to inject ${plugin} by itself, it was always a null
PluginDescriptor. Thus I have to inject three seperate values.
I have a sneaking suspicion that this may not work for users who
download a snapshot version of the plugin from a remote repository.
What's the best way to accomplish what I want?
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best way to extend install plugin?
Extending existing mojo's doesn't work very well, because the parameters for the extended mojo are not injected. Do you really need to subclass ? Can't you just write an additional mojo and bind that to the install phase, next to the ordinary install ? And when you have the OBR plugin, would you mind sharing it :) ? Tom On 2/17/07, Tim Moloney [EMAIL PROTECTED] wrote: Wendy Smoak wrote: On 2/17/07, Tim Moloney [EMAIL PROTECTED] wrote: I'd like to add a little extra functionality to the maven-install-plugin (create/update an xml file based on the jar being installed). Does your file go inside the jar, beside it in the repository, or somewhere else? Maven already writes and updates the xml metadata files in its repositories, so there should be some code to borrow if that's what you need to do. The file would be in the root of the local repository (~/.m2/repository/repository.xml) and allow the local repository to also be an OSGi bundle repository (OBR). I know that I can get things working by copying existing code into my plugin. However, that's not the best implementation from a maintenance point of view. I was hoping to write a plugin that called the code in maven-install-plugin (to keep present and future compatibility) and just add my little bit. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Download Sources
http://maven.apache.org/plugins/maven-dependency-plugin/sources-mojo.html On 2/15/07, gc134728 [EMAIL PROTECTED] wrote: I know but it's not all project that are set to interproject dependencies which causes a problem. It's also the mapping of generated foldes as source folder in eclipse. I'm trying to limit the knowledge people need about maven internals just operational knowledge is required. We split up the work so everybody can handle jobs retaining to their extensive knowledge. Other persons should just do a checkout from the svn repo, refresh there workspace build and bamm everything is setup. eclipse:eclipse can handle dependencies with other eclipse projects if it is ran from the top-level project. It will create .classpath .project files for all modules and respect inter-projects dependencies (see *useProjectReferenceshttp://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html#useProjectReferences *) Nico. 2007/2/15, gc134728 [EMAIL PROTECTED]: Hey dear maven users, I got a question. I have one person in our team that updates the pom.xmland creates the .classpath files namely MYSELF. But i attach sources to our own project artifacts but i want the other members of our team to get the attached sources when they download dependencies so they can view it in eclipse. The problem is they have to execute the eclipse:eclipse -DdownloadSources=true command. And this fucks up some .classpath files cause some projects have special eclipse project dependencies which i have to set manually. My question is how can i download the sources with the eclipse:eclipse plugin without the creation of the .project and .classpath file. Or is there an other way to download the sources? If there are no ideas i'm gonna tweak the eclipse:eclipse plugin. Thx for any assitance.--- Scarlet ONE - Combine ADSL with unlimited fixed phone and save 400 euros http://www.scarlet.be - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Scarlet ONE - Combine ADSL with unlimited fixed phone and save 400 euros http://www.scarlet.be - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JUnit 4.1 Surefire - Does Not Execute @Before @After methods
Make sure you are using a recent surefire snapshot. Out of the box Maven currently has no support for junit4. On 2/14/07, Subhash Chandran [EMAIL PROTECTED] wrote: I am using mvn 2.0.4. I have JUnit 4.1 test cases in my project. The methods I have marked with @After and @Before annotations do not get called during test execution. Is this a known bug, or am I doing something wrong? -- Regards, Subhash Chandran S http://wizcrypt.wiztools.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build-helper-maven-plugin: collecting ant build result
what is the packaging for your project ?
On 2/8/07, Jo Vandermeeren [EMAIL PROTECTED] wrote:
Hi again..
Forgot to include the plugin snippet of the pom.. Maven version is 2.0.4..
Cheers
Jo
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdbuild-helper-maven-plugin/artifactId
executions
execution
idattach-artifacts/id
phasepackage/phase
goals
goalattach-artifact/goal
/goals
configuration
artifacts
artifact
file${basedir}/dist/employee.ear/file
typeear/type
/artifact
/artifacts
/configuration
/execution
/executions
/plugin
On 2/8/07, Jo Vandermeeren [EMAIL PROTECTED] wrote:
The result of my ant build is an exploded ear, which is then jarred into
an ear.
When i use the buil-help-maven-plugin,to attach this ear to the maven
module for this component, I get following error:
[INFO] Building jar: /home/jo/projects/ystr/trunk/trax-ear/target/trax-
ear-3.2-SNAPSHOT.ear
[INFO] [build-helper:attach-artifact {execution: attach-artifacts}]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] An invalid artifact was detected.
This artifact might be in your project's POM, or it might have been
included transitively during the resolution process. Here is the information
we do have for this artifact:
o GroupID: com.trax
o ArtifactID: trax-ear
o Version: 3.2-SNAPSHOT
o Type:ear
[INFO]
[INFO] Trace
The module information above is the module's pom information.
As you can see, it has EAR packaging.. Is this a problem with the
build-helper plugin?
What I want to do is to trick maven into believing that this ear is the
ear that maven would build itself, if the project was a full maven project.
I believe that maven wants to attach the ant-built ear to this module and
produce a new ear, containing the attached artifact.
This is ofcourse not what I want.. I want to let maven rename the
ant-built ear, based on the groupId etc information in this module's pom.
Then install it in the repository as if it would be a plain old maven
artifact :)
Another step would be to stop the ant build at the exploded ear phase. So
maven can package up the directories into an ear of its own.
Has anyone done something similar?
Actually, since the client changed the specs of the produced artifacts, I
must also include another regular maven-built webapplication into the
above-mentioned ear.
This can become quite messy.. Since the entire project is maven-enabled,
except for this one ear that contains a legacy client/ejb/webapp
application.
So my other question is.. Is it possible to include the result of the
above-mentioned ant build (the exploded ear directories) in the
package-phase of another maven module?
This to let maven assemble a new ear, containing the contents of the
ant-build and the result artifact of a maven webapp module.
Thanks a bunch
Jo
On 1/19/07, Dan Tran [EMAIL PROTECTED] wrote:
you can attach the final Ant ear artifact to maven project so that it
can be
installed/deployed
as normal maven artifacts using build-helper-maven-plugin.
The draw back is the deployed pom has pom packaging. I dont know what
would be the impact
http://mojo.codehaus.org/build-helper-maven-plugin
-Dan
On 1/19/07, Jo Vandermeeren [EMAIL PROTECTED] wrote:
Hello fellow maven users,
I'm stuck with a legacy application that is built with ant and uses
lots
of
custom ant tasks.
There is no time to create maven plugins for this legacy project
instead.
Anyway.. The project I'm working on consists of two major artifacts.
- one ear with the legacy application (client)
- one ear with our new application (server)
I would like to build them together with maven, so i created a
POM-packaged
parent and seperate child modules for the new stuff and one child
module
for
the legacy application.
I use the antrun plugin to build the legacy ear, which seems to work
just
fine..
The next step is to tell maven to recognize the ear that is produced
by
the
ant build as a regular maven artifact and install it in the maven
repository.
Another possibility might be to produce the contents of the ear, but
not
yet
package it, so maven can package it and install the ear artifact in
the
repo.
Any ideas? I'm kind of in the dark
Re: build-helper-maven-plugin: collecting ant build result
I'm just guessing here: build-helper only works with attached
artifacts (adding a classifier to the config will probably solve this
but that's not what you want).
Can you have your ant build write its output to where maven would
normally put it ? Then you don't need to do configure anything...
Tom
On 2/8/07, Jo Vandermeeren [EMAIL PROTECTED] wrote:
It has ear packaging..
On 2/8/07, Tom Huybrechts [EMAIL PROTECTED] wrote:
what is the packaging for your project ?
On 2/8/07, Jo Vandermeeren [EMAIL PROTECTED] wrote:
Hi again..
Forgot to include the plugin snippet of the pom.. Maven version is 2.0.4
..
Cheers
Jo
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdbuild-helper-maven-plugin/artifactId
executions
execution
idattach-artifacts/id
phasepackage/phase
goals
goalattach-artifact/goal
/goals
configuration
artifacts
artifact
file${basedir}/dist/employee.ear/file
typeear/type
/artifact
/artifacts
/configuration
/execution
/executions
/plugin
On 2/8/07, Jo Vandermeeren [EMAIL PROTECTED] wrote:
The result of my ant build is an exploded ear, which is then jarred
into
an ear.
When i use the buil-help-maven-plugin,to attach this ear to the maven
module for this component, I get following error:
[INFO] Building jar:
/home/jo/projects/ystr/trunk/trax-ear/target/trax-
ear-3.2-SNAPSHOT.ear
[INFO] [build-helper:attach-artifact {execution: attach-artifacts}]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] An invalid artifact was detected.
This artifact might be in your project's POM, or it might have been
included transitively during the resolution process. Here is the
information
we do have for this artifact:
o GroupID: com.trax
o ArtifactID: trax-ear
o Version: 3.2-SNAPSHOT
o Type:ear
[INFO]
[INFO] Trace
The module information above is the module's pom information.
As you can see, it has EAR packaging.. Is this a problem with the
build-helper plugin?
What I want to do is to trick maven into believing that this ear is
the
ear that maven would build itself, if the project was a full maven
project.
I believe that maven wants to attach the ant-built ear to this module
and
produce a new ear, containing the attached artifact.
This is ofcourse not what I want.. I want to let maven rename the
ant-built ear, based on the groupId etc information in this module's
pom.
Then install it in the repository as if it would be a plain old maven
artifact :)
Another step would be to stop the ant build at the exploded ear phase.
So
maven can package up the directories into an ear of its own.
Has anyone done something similar?
Actually, since the client changed the specs of the produced
artifacts, I
must also include another regular maven-built webapplication into the
above-mentioned ear.
This can become quite messy.. Since the entire project is
maven-enabled,
except for this one ear that contains a legacy client/ejb/webapp
application.
So my other question is.. Is it possible to include the result of the
above-mentioned ant build (the exploded ear directories) in the
package-phase of another maven module?
This to let maven assemble a new ear, containing the contents of the
ant-build and the result artifact of a maven webapp module.
Thanks a bunch
Jo
On 1/19/07, Dan Tran [EMAIL PROTECTED] wrote:
you can attach the final Ant ear artifact to maven project so that
it
can be
installed/deployed
as normal maven artifacts using build-helper-maven-plugin.
The draw back is the deployed pom has pom packaging. I dont know
what
would be the impact
http://mojo.codehaus.org/build-helper-maven-plugin
-Dan
On 1/19/07, Jo Vandermeeren [EMAIL PROTECTED] wrote:
Hello fellow maven users,
I'm stuck with a legacy application that is built with ant and
uses
lots
of
custom ant tasks.
There is no time to create maven plugins for this legacy project
instead.
Anyway.. The project I'm working on consists of two major
artifacts.
- one ear with the legacy application (client)
- one
Re: build-helper-maven-plugin: collecting ant build result
The name of the output file is
${project.build.directory}/${project.build.finalName}.ear or something
similar
On 2/8/07, Jo Vandermeeren [EMAIL PROTECTED] wrote:
Hi Tom,
Smart thinking.. I could change the output directory.. Would that just be
the target/ folder then?
Is there a maven property for maven's output directory that I can pass to
the ant build?
Thanks
Jo
On 2/8/07, Tom Huybrechts [EMAIL PROTECTED] wrote:
I'm just guessing here: build-helper only works with attached
artifacts (adding a classifier to the config will probably solve this
but that's not what you want).
Can you have your ant build write its output to where maven would
normally put it ? Then you don't need to do configure anything...
Tom
On 2/8/07, Jo Vandermeeren [EMAIL PROTECTED] wrote:
It has ear packaging..
On 2/8/07, Tom Huybrechts [EMAIL PROTECTED] wrote:
what is the packaging for your project ?
On 2/8/07, Jo Vandermeeren [EMAIL PROTECTED] wrote:
Hi again..
Forgot to include the plugin snippet of the pom.. Maven version is
2.0.4
..
Cheers
Jo
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdbuild-helper-maven-plugin/artifactId
executions
execution
idattach-artifacts/id
phasepackage/phase
goals
goalattach-artifact/goal
/goals
configuration
artifacts
artifact
file${basedir}/dist/employee.ear/file
typeear/type
/artifact
/artifacts
/configuration
/execution
/executions
/plugin
On 2/8/07, Jo Vandermeeren [EMAIL PROTECTED] wrote:
The result of my ant build is an exploded ear, which is then
jarred
into
an ear.
When i use the buil-help-maven-plugin,to attach this ear to the
maven
module for this component, I get following error:
[INFO] Building jar:
/home/jo/projects/ystr/trunk/trax-ear/target/trax-
ear-3.2-SNAPSHOT.ear
[INFO] [build-helper:attach-artifact {execution:
attach-artifacts}]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] An invalid artifact was detected.
This artifact might be in your project's POM, or it might have
been
included transitively during the resolution process. Here is the
information
we do have for this artifact:
o GroupID: com.trax
o ArtifactID: trax-ear
o Version: 3.2-SNAPSHOT
o Type:ear
[INFO]
[INFO] Trace
The module information above is the module's pom information.
As you can see, it has EAR packaging.. Is this a problem with the
build-helper plugin?
What I want to do is to trick maven into believing that this ear
is
the
ear that maven would build itself, if the project was a full maven
project.
I believe that maven wants to attach the ant-built ear to this
module
and
produce a new ear, containing the attached artifact.
This is ofcourse not what I want.. I want to let maven rename the
ant-built ear, based on the groupId etc information in this
module's
pom.
Then install it in the repository as if it would be a plain old
maven
artifact :)
Another step would be to stop the ant build at the exploded ear
phase.
So
maven can package up the directories into an ear of its own.
Has anyone done something similar?
Actually, since the client changed the specs of the produced
artifacts, I
must also include another regular maven-built webapplication into
the
above-mentioned ear.
This can become quite messy.. Since the entire project is
maven-enabled,
except for this one ear that contains a legacy client/ejb/webapp
application.
So my other question is.. Is it possible to include the result of
the
above-mentioned ant build (the exploded ear directories) in the
package-phase of another maven module?
This to let maven assemble a new ear, containing the contents of
the
ant-build and the result artifact of a maven webapp module.
Thanks a bunch
Jo
On 1/19/07, Dan Tran [EMAIL PROTECTED] wrote:
you can attach the final Ant ear artifact to maven project so
that
it
can
Re: Dynamic dependencies
you can just add a dependency/ element to the plugin's configuration to override the original dependency On 1/31/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, I have a plugin (maven-jaxme-plugin), which currently has a static dependency on jaxme-0.5.2.jar. From time to time I add a bugfix to the dependency, which I would like to use in the plugin. However, it isn't very manageable to update the plugin anytime I update the dependency. So I am thinking whether it is possible to make jaxme a dynamic dependency. For example, I might check a special configuration parameter version. If that parameter is present, then I'd use the given version, otherwise I'd use the preconfigured 0.5.2. Does someone have an example how this can be done? Thanks, Jochen -- How fast can a year go? As fast as your childs first year. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Surefire, Cargo and Integration Tests
See http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing On 1/25/07, takai [EMAIL PROTECTED] wrote: Hi, i have problems integrating Cargo Deployment and Surefire Tests. I've bound cargo:start to pre-integration-test, surefire:test to integration-tests and finally cargo:stop to post-integration-test. The problem is that surefire executes twice. Once in test:test and once in integration-test. This gives me a headache. How do i tell surefire that it should execute *only* in integration-test? Looks like a surefire bug to me... Note: I used the jar lifecycle. Iff you use pom lifecycle (which does not bind a test:test phase) surefire only fires once in integration:test as it should. Note: It's Maven 2.0.4 and Surefire 2.2. Couldn't test the 2.3-SNAPSHOT since there's no public version available. Could someone pls confirm and i'll post a bug report. -- View this message in context: http://www.nabble.com/Surefire%2C-Cargo-and-Integration-Tests-tf3117463s177.html#a8635674 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: rebuild all dependent modules of the same project
It isn't possible. The only thing you can do is build toplevel - Maven will skip certain steps (like compile) if your projects haven't changed. Tom On 1/22/07, Sebastian Breit [EMAIL PROTECTED] wrote: Hi, this directory structure: main project (pom) module jar module webapp The webapp module has a dependency to the jar module. If i change the classes in the jar module i have to go into the jar module (mvn install) then i have to go into the webapp module and call mvn package or so - not very nice... How it is possible to call only mvn package in the webapp module and maven looks at all dependent modules of the same project and rebuild/reinstall all required modules? Sebastian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inheriting profiles
there was a thread about this last week (Jan 10 - Profile inheritance) On 1/18/07, Geoffrey De Smet [EMAIL PROTECTED] wrote: Is there any way to inherit profiles - more specifically their activation? In a multiproject I have a parent pom that has 2 profiles: development and production. Development needs to be activated by default everywhere. Now I found myself repeating the activation in each child pom. -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shared Repository Access Problem
specify your own repository as a mirror for central http://maven.apache.org/guides/mini/guide-mirror-settings.html On 1/18/07, Alauddin [EMAIL PROTECTED] wrote: Hi, I setup and deployed the repository folder to the apache server. It works fine. I got them from browser. I setup my conf/settings.xml file like the following . default-repositories central Internal Mirror of Central Repository http://crmserver/maven2/repository central Internal Mirror of Central Plugins Repository http://crmserver/maven2/repository ... But mvn deploy .always goto http://repo1.maven.org Site. How can i overwrite the new repository in place of remote repo1.maven.org repository. Any help appriciated Alauddin -- View this message in context: http://www.nabble.com/Shared-Repository-Access-Problem-tf3032826s177.html#a8426586 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Your First Plugin Tutorial error ???
On 1/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
I'm want to write my own plugin to build my company's project.
Now I'm following the Your First Plugin Totorial on
http://maven.apache.org/guides/plugin/guide-java-plugin-development.html
.
I've installed the hello-maven-plugin in my local repository.
Now I want to run this plugin via the command line, mvn
sample.plugin:maven-hello-plugin:1.0-SNAPSHOT:sayhi.
I get the following error:
C:\eGovDev\Maven Pluginsmvn
sample.plugin:maven-hello-plugin:1.0-SNAPSHOT
where did the :sayhi go ?
[INFO] Scanning for projects...
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.plugin.descriptor.PluginDescriptor.getMojo(PluginDes
criptor.java:259)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor
(DefaultLifecycleExecutor.java:1524)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListBy
AggregationNeeds(DefaultLifecycleExecutor.java:381)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:135)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Wed Jan 17 10:35:35 CET 2007
[INFO] Final Memory: 1M/4M
[INFO]
They say something about the goal annotation, that it is needed, but is
it needed in the source code of the mojo ?
Here's the source code:
package sample.plugin;
import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugin.MojoFailureException;
/**
* Says Hi to the user.
* @goal sayhi
*/
public class GreetingMojo extends AbstractMojo
{
public void execute() throws MojoExecutionException,
MojoFailureException
{
getLog().info(Hello, world.);
}
}
The @goal annotation is in comment, but when i write the annotation, i
get an error.
It isn't recognised as an annotation.
I guess the FATAL ERROR appears because there's no sayhi annotation.
But how can I add it to this class file ?
Kind regards.
Jelle
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in
error, please notify the sender immediately and delete the original. Any other
use of the email by you is prohibited.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: release:prepare
during release:prepare the release plugin will need to change the versions in the pom and make commits. You can't do that if you do not have the latest versions of your poms, right ? An alternative would be to create a branch based on a revision, and release from there. Tom On 1/16/07, alexsil [EMAIL PROTECTED] wrote: Thank you for the answer Marc, but tag is the name of the tag not the revision. Bye Alex marc gassmann wrote: alexsil said the following on 16.01.2007 11:20: Is possible force a revision to use during release:prepare o release:perform instead of use a default HEAD revision ??? Thanks in advance I didnt tried it ... but my guess is 'tag' have a look here. it could be the same as in maven 1 http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#tag cheers marc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/release%3Aprepare-tf3020091s177.html#a8391351 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release:prepare
you have to decide what you need: - if you really are releasing a historical version, you probably don't want the modified poms in trunk - if you do want them, you should merge branch to trunk On 1/16/07, alexsil [EMAIL PROTECTED] wrote: Sorry Tom, but if I use a Branch instead of Trunk maven release plugin commit the next version pom on the Branch and not on the Trunk that is the right place ??? Is it true Thanks Alex Tom Huybrechts wrote: during release:prepare the release plugin will need to change the versions in the pom and make commits. You can't do that if you do not have the latest versions of your poms, right ? An alternative would be to create a branch based on a revision, and release from there. Tom On 1/16/07, alexsil [EMAIL PROTECTED] wrote: Thank you for the answer Marc, but tag is the name of the tag not the revision. Bye Alex marc gassmann wrote: alexsil said the following on 16.01.2007 11:20: Is possible force a revision to use during release:prepare o release:perform instead of use a default HEAD revision ??? Thanks in advance I didnt tried it ... but my guess is 'tag' have a look here. it could be the same as in maven 1 http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#tag cheers marc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/release%3Aprepare-tf3020091s177.html#a8391351 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/release%3Aprepare-tf3020091s177.html#a8393628 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCM URL for the maven-surefire-plugin
These patches in MSUREFIRE-31 have already been applied to trunk. http://svn.apache.org/viewvc/maven/surefire/trunk/ On 1/16/07, Lasse Koskela [EMAIL PROTECTED] wrote: Hi, I'm in the process of figuring out whether I can get one of the surefire-and-junit4 patches working and found out that a wrong URL to the Subversion repository is posted on the Source repository page at http://maven.apache.org/plugins/maven-surefire-plugin/source-repository.html Apparently it should point to: http://svn.apache.org/repos/asf/maven/surefire/trunk/maven-surefire-plugin Lasse - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release:prepare
would this help: http://maven.apache.org/plugins/maven-release-plugin/examples/lock-files.html ? On 1/16/07, alexsil [EMAIL PROTECTED] wrote: Ok, you are right, but I think to have exposed bad my problem. I don't want to release a historical version. I want to be sure that while I'm releasing a new version nobody can make a commit that invalid the version of code of the created TAG against the binary (in the maven repository) that will be deployed in server-farm. More deeply: the maven release process doesn't update the code, but get the latest version from tha Maven repository. The binary present in the MAVEN repository correspond to a SVN revision. If the TEST process gives the OK, the binary will be depoyed in server farm. But when I use Maven plugin to to this, the tag created from Trunk sure doesn't correspond to binary because in the time passed from release in TEST ed OK TEST several commits are done on Trunk from developers. Bye Alex. Tom Huybrechts wrote: you have to decide what you need: - if you really are releasing a historical version, you probably don't want the modified poms in trunk - if you do want them, you should merge branch to trunk On 1/16/07, alexsil [EMAIL PROTECTED] wrote: Sorry Tom, but if I use a Branch instead of Trunk maven release plugin commit the next version pom on the Branch and not on the Trunk that is the right place ??? Is it true Thanks Alex Tom Huybrechts wrote: during release:prepare the release plugin will need to change the versions in the pom and make commits. You can't do that if you do not have the latest versions of your poms, right ? An alternative would be to create a branch based on a revision, and release from there. Tom On 1/16/07, alexsil [EMAIL PROTECTED] wrote: Thank you for the answer Marc, but tag is the name of the tag not the revision. Bye Alex marc gassmann wrote: alexsil said the following on 16.01.2007 11:20: Is possible force a revision to use during release:prepare o release:perform instead of use a default HEAD revision ??? Thanks in advance I didnt tried it ... but my guess is 'tag' have a look here. it could be the same as in maven 1 http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#tag cheers marc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/release%3Aprepare-tf3020091s177.html#a8391351 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/release%3Aprepare-tf3020091s177.html#a8393628 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/release%3Aprepare-tf3020091s177.html#a8394965 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inheriting plugin executing
Add inheritedfalse/inherited to the plugin/ element. On 1/15/07, Saminda Abeyruwan [EMAIL PROTECTED] wrote: Hi All, Say my parent pom.xml has a pluging to execute some goal on the initialization phase. If this pom is the parent of app1 pom.xml and app2 pom.xml ie pom.xml - app1 pom.xml - app2 pom.xml when the reactor is working, the code in the initialization phase repeats. Is there a way to stop this. Only parent pom.xml will do some unit of work, but it doesn't need to inherit to its children poms. Thank you Saminda -- Saminda Abeyruwan Software Engineer WSO2 Inc. - www.wso2.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Snapshot plugin repository - where is it now...
http://snapshots.repository.codehaus.org/ http://repository.codehaus.org/ See links at the top of http://mojo.codehaus.org On 1/15/07, Darren Hartford [EMAIL PROTECTED] wrote: Trying to maintain consistency with an evolving platform Trying to download the maven-ejb-plugin-2.1-SNAPSHOT that was originally at *http://snapshots.maven.codehaus.org/maven2/plugins *http://snapshots.maven.codehaus.org/maven2 That website is no longer available. Where is the new location? Thanks, -D - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can you compile test cases without running them
-Dmaven.test.skip.exec in the surefire snapshot version On 1/15/07, jp4 [EMAIL PROTECTED] wrote: I would like to be able to compile my test cases without actually running them. I use maven.test.skip=true but that seems to prevent not only the test execution but the test compilation. Is there a way to compile without running test cases. I would prefer not to mess with the pom files, but do it via the command line like -Dmaven.test.skip=true. Thanks, jp4 -- View this message in context: http://www.nabble.com/Can-you-compile-test-cases-without-running-them-tf3016005s177.html#a8375655 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with maven-ear-plugin version 2.3
I had the same problem today
Let me quote somebody:
you can still make it work if you explicitely set the resources directory
configurationresourcesDir${project.build.outputDirectory}/resourcesDir
/configuration
tom
On 1/11/07, Tobias Jenkner [EMAIL PROTECTED] wrote:
Hello,
when I use the maven-ear-plugin in its latest (released) version 2.3, it
seams that the plugin does not copy the resources any more. The build
fails because it cannot locate the application.xml any more:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Deployment descriptor:
c:\Workspace\server\application\target\mpa-application-M2-SNAPSHOT\META-INF\application.xm
l does not exist.
When I use the old version 2.2 everything works fine.
Is this a bug or is the fault on my side? Do I have to change my maven
configuration when using version 2.3?
Issue MEAR-47 is about removing the resourcesDir property - did that
influence the resource handling in general?
thanks for your comments,
Tobias.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with maven-ear-plugin version 2.3
I don't know why the defaults changed...
If you want the previous behaviour, fix your plugin version to 2.2
On 1/11/07, Tobias Jenkner [EMAIL PROTECTED] wrote:
I do not understand the reason for this change?
why do I have to configure the resources directory on my own? the maven
approach is convention over configuration, isn't it?
or is it deprecated to use resources in this place? where should I place
them instead?
thanks for your help, Tobias.
Tom Huybrechts schrieb:
I had the same problem today
Let me quote somebody:
you can still make it work if you explicitely set the resources directory
configurationresourcesDir${project.build.outputDirectory}/resourcesDir
/configuration
tom
On 1/11/07, Tobias Jenkner [EMAIL PROTECTED] wrote:
Hello,
when I use the maven-ear-plugin in its latest (released) version 2.3, it
seams that the plugin does not copy the resources any more. The build
fails because it cannot locate the application.xml any more:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Deployment descriptor:
c:\Workspace\server\application\target\mpa-application-M2-SNAPSHOT\META-INF\application.xm
l does not exist.
When I use the old version 2.2 everything works fine.
Is this a bug or is the fault on my side? Do I have to change my maven
configuration when using version 2.3?
Issue MEAR-47 is about removing the resourcesDir property - did that
influence the resource handling in general?
thanks for your comments,
Tobias.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
