be affected by this
change.
I am a little uneasy, however, using a 'beta' version of the artifact.
Beta-6 seems to be the latest/best available. Is this the case?
Thanks for the help.
Brad
From: Harper, Brad
Sent: Friday, October 29, 2010 5:22 PM
To: users@maven.apache.org
Subject
I just switched [from Maven 2.2.1] to give 3.0 a try and ran into a
problem during deployment. The crux of the output seems to be
No implementation for org.apache.maven.wagon.Wagon annotated with
@Named(value=scp) was bound
Nothing obvious jumps out in a web search containing key parts
I've noticed [1], indicating that a plugin that supports use of NSIS
with Maven 2.
It appears from the example [2] that the associated maven project
packaging is 'pom' and implies that the installer payload be present
within the project itself.
I'm interested in building a substantially
While trying to keep our third-party dependencies current, we found that
[1] reports a version 1.1.1 available for javax.activation:activation
... yet no such artifact version appears to exist in the central maven2
repo.
On the other hand, [2] reports this version for the JavaBeans Activation
I didn't see one, so I added one. Refer to
http://jira.codehaus.org/browse/MWAR-194.
Thanks.
Brad
-Original Message-
From: Mark Hobson [mailto:markhob...@gmail.com]
Sent: Wednesday, May 13, 2009 3:37 AM
To: Maven Users List
Subject: Re: War Overlays and Conflicting Jars
2009/5/12 Brad
credentials for scp.
On Tue, May 5, 2009 at 6:33 PM, Harper, Brad brad.har...@fiserv.com
wrote:
While performing a deployment from the release plugin, I see
[INFO] [INFO] [install:install]
[INFO] [INFO] Installing C:\eclipse-workspaces\...\x.war to
C:\...\.m2\repository\com\...\x.war
[INFO
Is there a way to detect when the dependencies of two war artifacts are
inconsistent with respect to packaged jar versions?
E.g. a war depends on artifact abc-1.0.0.jar. An overlay is performed
where an inconsistent dependency on abc-1.0.1.jar is also defined.
The resulting war will
While performing a deployment from the release plugin, I see
[INFO] [INFO] [install:install]
[INFO] [INFO] Installing C:\eclipse-workspaces\...\x.war to
C:\...\.m2\repository\com\...\x.war
[INFO] [INFO] Installing C:\eclipse-workspaces\...\x-sources.jar to
It's established that links won't work for deployment of multi-module
sites [1], i.e. links don't work for
% mvn site site:deploy
But I can get
% mvn site:stage-deploy
to deploy a 'staged' site to a remote URL [even the same URL specified
by
I've configured the [2.1] maven-assembly-plugin to generate a zip file
with an execution bound to the 'package' phase [goal is 'attached'].
It's in the build element within a profile with idreleasing/id.
Running
% mvn release:prepare release:perform -Preleasing
does not generate a zip file.
-
From: Harper, Brad
Sent: Friday, December 19, 2008 4:20 PM
To: 'Maven Users List'
Subject: Inconsistent Cobertura Results
Sometimes cobertura reports zero percent coverage in info
produced by site:site, and non-zero percentages are reported
when run separately.
I was thinking
Sometimes cobertura reports zero percent coverage in info produced by
site:site, and non-zero percentages are reported when run separately.
I was thinking that this might be due to differences in the default
values of the property maven.compiler.debug between the build and site
lifecycles ... or
I've been struggling with multi-module site deployment [via scp] in
conjunction with the dashboard reporting plugin and am convinced that it
must be due to a basic misunderstanding about expected behavior on my
part.
From http://maven.apache.org/plugins/maven-site-plugin/plugin-info.html,
I see
But this issue isn't a problem with the dashboard plugin, or even a
question as to whether the JDepend reports can be rolled up
meaningfully. I was describing the expected final use case. Maybe
summarizing data doesn't make sense for JDepend. Hopefully the dashboard
plugin will [some day?] be able
Does anyone have experience running the JDepend reporting plugin in a
multi-module project?
We've been able to successfully run the subject plugin [via site:site]
in individual projects with packaging types of jar and war, but when
performing
mvn jdepend:generate
in the top-level project
not making it to local repo
On Thu, Nov 13, 2008 at 5:33 PM, Harper, Brad
[EMAIL PROTECTED] wrote:
I was hoping that build number would let us iteratively refine an
artifact in UAT without relying on version number alone.
Do you require the full release process with a tag for every
www.iprofs.nl
On Fri, Nov 14, 2008 at 1:44 AM, Wendy Smoak [EMAIL PROTECTED] wrote:
On Thu, Nov 13, 2008 at 5:33 PM, Harper, Brad
[EMAIL PROTECTED] wrote:
I was hoping that build number would let us iteratively refine an
artifact in UAT without relying on version number alone.
Do
For anyone who has experience with the buildnumber plugin ...
The only examples that I see bind the execution of the plugin to the
'validation' phase of the build lifecycle.
For my purpose, it makes sense to have a build number attached to the
artifact, but only when deployed to an internal
I've configured a site element in distributionManagement to use scp.
When performing
% mvn site:deploy
I'm prompted for my password before the action begins. It completes
successfully. The question ...
Is there a way to configure the authentication for the site deployment
operation, in the
Meaning that I define another server element under servers in the
settings.xml and refer to the id defined for the site element in
distributionManagement?
Brad
-Original Message-
From: Edelson, Justin [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2008 2:55 PM
To:
repository or
deploy to a remote repository with another name, afaik.
With regards,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Thu, Nov 13, 2008 at 6:27 PM, Harper, Brad
[EMAIL PROTECTED] wrote:
For anyone who has
I've configured the buildnumber plugin to attach a timestamp thusly
finalName${project.artifactId}-${project.version}-${buildNumber}/fina
lName
and the [jar] artifact is produced in the target/ directory as expected.
But the build number is not carried into the local repo when installing
the
Smoak [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2008 6:19 PM
To: Maven Users List
Subject: Re: buildnumber value not making it to local repo
On Thu, Nov 13, 2008 at 5:14 PM, Harper, Brad
[EMAIL PROTECTED] wrote:
I've configured the buildnumber plugin to attach a timestamp
for that.
On Tue, Sep 23, 2008 at 2:34 PM, Harper, Brad
[EMAIL PROTECTED] wrote:
So it sounds like your 'staging' repo is for a semi-formal
QA process,
like what we call User Acceptance Test [UAT] and the plugin
is used to
promote the entire repository to a final/production repo.
But you
Can anyone comment on the purpose [and status] of the 'stage' plugin?
Apart from the statement
Its main use is for copying artifacts from a staging repository
to the real repository.
at http://maven.apache.org/plugins/maven-stage-plugin/, there isn't
much explanation. I don't find many
public repo. This plugin makes the
process easier
and reduces errors.
You can probably find more info about this plugin in the Maven Dev
list archives.
Wayne
On Tue, Sep 23, 2008 at 1:38 PM, Harper, Brad
[EMAIL PROTECTED] wrote:
Can anyone comment on the purpose [and status
-plugin currently in the sandbox.
Give it a try and feedback
On Tue, Sep 23, 2008 at 2:43 PM, Dan Tran [EMAIL PROTECTED] wrote:
there already a JIRA for that.
On Tue, Sep 23, 2008 at 2:34 PM, Harper, Brad
[EMAIL PROTECTED] wrote:
So it sounds like your 'staging' repo is for a semi
[x] Our team does not use HTTP or the file system because
a rabidly security conscious admin insisted on using scp. It's
been the source of unnecessary headaches ever since, especially
in cross-platform settings.
[x] Our team intends to use HTTP to retrieve our artifacts
as we
I think you'll find that PMD supports cyclomatic complexity. There's a
m2 plugin described at
http://maven.apache.org/plugins/maven-pmd-plugin/
Brad
-Original Message-
From: aldana [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 22, 2008 7:23 AM
To: users@maven.apache.org
Anyone else have ideas? I'm still spinning my wheels on this issue.
Thanks.
Brad
-Original Message-
From: Harper, Brad
Sent: Friday, April 18, 2008 11:25 AM
To: 'Maven Users List'
Subject: RE: maven-war-plugin:2.0.2 confuses relative path
when run in the reactor
No good. I
path
when run in the reactor
It looks like the plugin is running in your parent, which is
probably not what you wanted. You want this to be inherited
but not run, so put it in the pluginManagment section instead.
-Original Message-
From: Harper, Brad [mailto:[EMAIL PROTECTED
?
-Original Message-
From: Harper, Brad [mailto:[EMAIL PROTECTED]
Sent: Friday, April 18, 2008 12:25 PM
To: Maven Users List
Subject: RE: maven-war-plugin:2.0.2 confuses relative path
when run in the reactor
No good. I moved the plugin element for maven-war-plugin in
the parent
I'm seeing a problem that appears to be nearly identical to one posted
here
in the recent past. See
http://www.mail-archive.com/users@maven.apache.org/msg77272.html
and the subsequent thread. The issue didn't seem to be obviously
resolved at that time.
The command line 'mvn install' works
It looks like there's been some progress made in this area since I last
looked into it, specifically the jade-native plugin [from jfrog.org] and
the NAR plugin [from freehep.org].
I'm returning to a dormant project originally set to use the maven
native plugin, and am trying to decide on a
On Apr 10, 2008, at 8:34 AM, Harper, Brad wrote:
Anyone have thoughts on what's behind the following error?
...
[ERROR] BUILD FAILURE
[INFO] --
[INFO] The assembly id null is used more than once.
...
I see this error when testing a garden-variety assembly
at 12:44 PM, Harper, Brad
[EMAIL PROTECTED]
wrote:
Ah, thanks.
I've since found that mvn assembly:attached works, both from the
command line and when run as part of a maven build
lifecycle [with the
same assembly descriptor.]
Is the assembly id being inferred or derived from
Anyone have thoughts on what's behind the following error?
...
[ERROR] BUILD FAILURE
[INFO] --
[INFO] The assembly id null is used more than once.
...
I see this error when testing a garden-variety assembly from the command
line
% mvn assembly:assembly
Greetings:
We've begun committing release notes to an svn repository. I'd like to
extract the document during a release and bundle it with a project
artifact via the assembly plugin. I'm attempting to use the scm plugin
attached to the 'process-resources' phase in preparation for the
assembly,
Hi:
Has anyone started using the recently added emma plugin for maven2?
The plugin goals aren't well described yet. The Plugin Goals page is
empty. The groupId and artifactId in an example on the How to Use page
looks like it may be referring to maven1 plugin. [See
Hi:
I've suddenly been hit by the problem described at
http://jira.codehaus.org/browse/SCM-213
when running the 'release:prepare release:perform' goals.
The svn command-line client fails when receiving an argument containing
duplicate paths using two different conventions: one cygwin, the
40 matches
Mail list logo
