I'm hoping someone can explain some odd behavior I'm seeing and suggest
a solution.
I have a multi-module project that makes use of two different versions
of the assembly plugin on purpose. There's functionality that is only
available in the 2.2-beta-2 version that is required for one particular
You may want to look at the Maven Ant Tasks. They're very useful to
integrating Ant with Maven's dependency management and artifact
handling.
http://maven.apache.org/ant-tasks/index.html
-Original Message-
From: quin...@skywalk.co.za [mailto:quin...@skywalk.co.za] On Behalf Of
Quintin B
So you need to define a dependency for each one of these individual
spring artifacts in your build in order to override the version.
-Original Message-
From: Wim Deblauwe [mailto:wim.debla...@gmail.com]
Sent: Monday, October 12, 2009 5:11 AM
To: Maven Users List; jeffma...@jeffmaury.com
S
change all your projects to reference these (since you just
keep referencing the POM which references these).
Quintin Beukes
On Tue, Oct 13, 2009 at 4:17 PM, Jamie Whitehouse
wrote:
> So you need to define a dependency for each one of these individual
> spring artifacts in your build
ns?
I see. That's not good at all. There is no way to "provide"
dependencies which have a different artifact id.
Any reason why you depend on this one?
Quintin Beukes
On Tue, Oct 13, 2009 at 6:58 PM, Jamie Whitehouse
wrote:
> The Spring project produces a complete spring artifac
Are you passing these to surefire as system properties?
http://maven.apache.org/plugins/maven-surefire-plugin/examples/system-properties.html
If not, how are you passing them?
-Original Message-
From: Roland Asmann [mailto:roland.asm...@cfc.at]
Sent: Thursday, October 15, 2009 2:13 PM
ubject: Re: Unexplained Animal Sniffer errors with JSPC plugin
well that version of animal sniffer is Kohsuke's
I have not released the migrated to codehaus version yet
Looks like you are missing a dependency or two for your jar (probably
jasper-runtime and servlet-api)
-Stephen
2009/10/
plugin I am trying to release is
maven-invoker-plugin:1.5 which, all going well, will be staged
today/tomorrow (after brian finishes updating repository.apache.org to
sonatype nexus 1.4)
dizzy yet?
-Stephen
2009/10/23 Jamie Whitehouse
> Yes it's Kohsuke's original version since
I was just about to ask that, if the 1.5 home was symlinked to 1.6.
You may want to consider the animal-sniffer plugin to detect and error
on Java API incompatibles. The one from Codehaus mojos should be out
shortly, in the mean time Kohsuke's is working for me.
-Original Message-
From:
You may want to look at the exec-maven-plugin which can execute programs
outside of Maven:
http://mojo.codehaus.org/exec-maven-plugin/
-Original Message-
From: Gajo Csaba [mailto:csaba.g...@cosylab.com]
Sent: Monday, November 09, 2009 5:13 AM
To: Maven Users List
Subject: Maven Archetype
You can use the build helper plugin to attach additional artifacts to be
installed and deployed. This will mean that hashes will be created for
you.
See
http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.
html
-Original Message-
From: Steve Brannstrom [mailto:steveb
I have used this many times and can assure you it works.
How are you calling the release goals? In one line or as different
steps?
-Original Message-
From: Johannes Schneider [mailto:maili...@cedarsoft.com]
Sent: Thursday, November 12, 2009 12:43 PM
To: users@maven.apache.org
Subject: r
No, it's http that you want.
Since you used file initially you'll probably see your artifacts on your
local disk in a directory like
myserver:8081/nexus/content/repositories/myRepo/
-Original Message-
From: Neil Chaudhuri [mailto:nchaudh...@potomacfusion.com]
Sent: Thursday, November 12,
You could use the maven-exec or maven-antrun plugins and bind those to
the phase that you need. See
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycl
e.html#Lifecycle_Reference .
If you really need it to run after Maven has installed the artifacts
into the local repo I thin
AFAIK dependency tree does not run in the reactor. Is mod_d depending
on a SNAPSHOT version of mod_c? Do you have that version installed in
your local repo?
I have used dependency tree many time on a large mutli-module project so
I can attest that it does work in some form.
-Original Messa
What maven commands did you issue to test this?
I used the attached project and here's the results.
1) extract zip
2) mvn dependency:tree
failed due to dependency resolution
3) mvn clean install
4) mvn dependency:tree
see the tree output
I think you're misunderstanding how the local maven rep
jon
On Thu, Nov 19, 2009 at 11:43:33AM -0800, Jamie Whitehouse wrote:
> What maven commands did you issue to test this?
>
> I used the attached project and here's the results.
> 1) extract zip
> 2) mvn dependency:tree
> failed due to dependency resolution
> 3) mvn clean insta
tree goal to completely work around
> this? Probably, but it would mean duplicating tons of core logic to
> make the resolution work in all cases and running tree on a not-yet
> compiled or installed project is an edge case imo.
>
>
> 2009/11/19 Jamie Whitehouse :
> >
I was about to reply with the same thing. The Maven way is to install
artifacts. Many plugins, rightly or not, depend on artifacts being
located in the local repository.
-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com]
Sent: Tuesday, November 24, 2009 4:53 PM
To: Maven Use
As you suggest you can also read them in from somewhere. Create a test
resources property file that gets filtered and read that. Much simpler
and easier to maintain when there's more than a few properties.
-Original Message-
From: Dan Tran [mailto:dant...@gmail.com]
Sent: Wednesday, Dec
Just want to note: that is good advise if you want to release the modules
separately from the top-level. It's not strictly necessary if you aren't or if
you SCM doesn't support releasing from subdirectories (e.g. Mercurial).
-Original Message-
From: Dan Tran [mailto:dant...@gmail.com]
I haven't tried this but I think t may work. You could use mvn
dependency:go-offline -Dmaven.repo.local=/some/archive/path
This should cause all the required dependencies and plugins to be
downloaded to the maven.repo.local path you specified. If you ran that
on all of your projects you'd have a
The use of an explicit version is the problem. Instead of
0.0.3-SNAPSHOT try depending on ${project.version}. In my experience
using the fixed version the assembly plugin (and others like the
dependency copy goals) will use what's in the local repo not what's in
the reactor.
> -Original Mess
I think you want to be using a maven-resources-plugin that's version
2.4.1 or greater, see MRESOURCES-100 and MRESOURCES-106.
http://jira.codehaus.org/browse/MRESOURCES-100
http://jira.codehaus.org/browse/MRESOURCES-106
> -Original Message-
> From: Laird Nelson [mailto:ljnel...@gmail.com
On Wed, Sep 8, 2010 at 9:49 AM, Brian Fox wrote:
> We need your help to determine what
> else needs to be fixed before the final release. So if you haven't
> yet, we would like you to grab the latest 3.x build and give us your
> feedback. You can find the download link here:
> http://maven.apache
25 matches
Mail list logo