On Wed, Sep 8, 2010 at 9:49 AM, Brian Fox bri...@infinity.nu 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:
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]
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
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
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]
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,
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
the dependency 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 jamie.whiteho
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
, 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 install
4) mvn dependency:tree
see the tree output
I think you're
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
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
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:
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
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
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
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:
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/23 Jamie Whitehouse jamie.whiteho...@genesyslab.com
I recently discovered that animal sniffer will throw errors with
precompiled jsps. I've
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 jamie.whiteho...@genesyslab.com
Yes it's Kohsuke's original
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
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
referencing the POM which references these).
Quintin Beukes
On Tue, Oct 13, 2009 at 4:17 PM, Jamie Whitehouse
basil.whiteho...@genesyslab.com wrote:
So you need to define a dependency for each one of these individual
spring artifacts in your build in order to override the version
. 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
basil.whiteho...@genesyslab.com wrote:
The Spring project produces a complete spring
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
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
25 matches
Mail list logo
