Ahh, I thought you had to use "Clone" to get a copy of the issue. My bad.
--
Dennis Lundberg
Arnaud HERITIER wrote:
I moved a copy to not forget to do it in maven 1 but I forgot to update the
description
Arnaud
On 10/12/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Arnaud Heritier (JIRA) w
Folks... maven's handling of *SNAPSHOT artifacts is killing us. Any
idea what is going on... and how we can fix this. Its an ongoing
problem, seems like new timestamp mismatch problems are popping up
quite often now. I've already removed our direct use of m1 repos to
get around some prob
On 13 Oct 06, at 2:04 PM 13 Oct 06, Eric Redmond wrote:
Then +1 if its moved out of the sandbox.
Yup, I'll move it out of the sandbox as part of the release.
Jason.
On 10/13/06, John Casey <[EMAIL PROTECTED]> wrote:
It's actually meant to allow you to fork a new Maven build for
whate
Then +1 if its moved out of the sandbox.
On 10/13/06, John Casey <[EMAIL PROTECTED]> wrote:
It's actually meant to allow you to fork a new Maven build for whatever
reason, but yes, it does have a little bit of minimal verification
functionality that will allow it to be an effective replacement
I'm delighted to see these issues addressed. A few small comments below.
On 10/13/06, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
The maven release process criticism from Dan Kulp spawned an impromptu
ApacheCon gathering of the minds (Dan Kulp, Wendy Smoak, Jason Van Zyl,
and Myself) to define
The maven release process criticism from Dan Kulp spawned an impromptu
ApacheCon gathering of the minds (Dan Kulp, Wendy Smoak, Jason Van Zyl,
and Myself) to define a better release process for maven.
We covered the needs of Apache with regards to
* Apache Top Level Poms (and Incubator requ
It's actually meant to allow you to fork a new Maven build for whatever
reason, but yes, it does have a little bit of minimal verification
functionality that will allow it to be an effective replacement for the it
plugin.
There are a couple of other features we need to consider for a real IT
solu
Hi John, Kenney and others,
I did an attempt to perform IT tests for a Plugin project and I want
your feedback.
I used a profile (already suggested by John) with:
* maven-clean-plugin to clean src/it/**/target
* maven-install-plugin to install a snapshot of the plugin on
/target/local-repo (an r
Take a look in the same link below. In the resolvers/ subfolder is a
mojo to resolve project plugins and their dependencies, the code you
want would be in there.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, October 13, 2006 5:12 AM
To: Maven Develope
On 10/12/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
On Oct 12, 2006, at 8:15 AM, John Casey wrote:
> 1. I don't think anyone can complain with compliance issues. One
> thing I
> would say is, we could/should be using a plugin to resolve the
> license file
> from the url given in the POM, and in
It is more an issue with wagon while deploying, WAGON-19
On 10/13/06, Vincent Siveton <[EMAIL PROTECTED]> wrote:
Hi,
I was unable to deploy a snapshot in
/www/.../plugins/maven-install-plugin due to a permission denied.
So, I created:
* a copy of the maven-install-plugin dir to
/www/.../plugin
Should be "umask 0002" in ~/.profile
You could also check wrong permissions on maven-snapshot-repository
http://people.apache.org/maven-snapshot-repository/README
Cheers,
Vincent
2006/10/13, Stephane Nicoll <[EMAIL PROTECTED]>:
How do we fix this?
On 10/13/06, Vincent Siveton <[EMAIL PROTECT
How do we fix this?
On 10/13/06, Vincent Siveton <[EMAIL PROTECTED]> wrote:
Hi,
I was unable to deploy a snapshot in
/www/.../plugins/maven-install-plugin due to a permission denied.
So, I created:
* a copy of the maven-install-plugin dir to
/www/.../plugins/.maven-install-plugin.BAK
* copy th
Hi,
I was unable to deploy a snapshot in
/www/.../plugins/maven-install-plugin due to a permission denied.
So, I created:
* a copy of the maven-install-plugin dir to
/www/.../plugins/.maven-install-plugin.BAK
* copy the content of this BAK to a new /www/.../plugins/maven-install-plugin
* and fix
On 13 Oct 06, at 4:11 AM 13 Oct 06, [EMAIL PROTECTED] wrote:
"Dan Tran" <[EMAIL PROTECTED]> schrieb am 12.10.2006 12:14:47:
How do I determine the absolute path for a JAR in the repository?
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-
dependency-plugin
Look for Copy Artifac
Hi,
Try instead of the following:
public class DashBoardReportMojo
extends DashBoardMojo
implements MavenReport
DashBoardMojo uses post-site
Cheers,
Vincent
2006/10/9, dvicente <[EMAIL PROTECTED]>:
nobody can help me ?
http://www.nabble.com/-M2--dashboard-report-plugin-tf2342819.html
Ok, I guess I'm still not used to the "maven way" :-) The code in
ResolvePluginsMojo was confusing to me until I walked up the class
hierarchy. Here is what I came up with:
/**
* Used to look up Artifacts in the remote repository.
*
* @parameter
expression="${component.org.a
"Dan Tran" <[EMAIL PROTECTED]> schrieb am 12.10.2006 12:14:47:
> > How do I determine the absolute path for a JAR in the repository?
>
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-dependency-plugin
>
> Look for Copy Artifact/Dependency, etc
That's only for project dependencies. I n
Daniel Kulp <[EMAIL PROTECTED]> schrieb am 12.10.2006 16:36:57:
> 1) The LICENSE/NOTICE files in the META-INF dir of the jar - currently,
> none of the maven plugins do this at all. I've seen projects handle
> this in a couple different ways. Some projects put them in the
> src/main/resourc
19 matches
Mail list logo
