Hi,
If you want to get something done in the release plugin then vote
with JIRA:
http://jira.codehaus.org/browse/MRELEASE
I'll do as many of the most voted for issues I can in the day I can
spend on the release plugin:
You can look here for what's been voted on so far:
http://repo1.mave
Hi,
For anyone who wants to ask for something in a plugin vote and from
this template and swizzle:
http://svn.apache.org/repos/asf/maven/sandbox/reports/maven-plugins.vm
We will produce this:
http://repo1.maven.org/reports/plugins/plugin-issues.txt
So if you want to have your voice heard t
+1
But I would prefer to see an upgrade to PMD 3.8 before release.
On 11/5/06, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
Hi,
It has been 3 months since the last release of the maven-pmd-plugin,
Since then, there has been a refactoring of the excludes logic to bring
harmony to the pmd and cpd
On 6 Nov 06, at 9:29 AM 6 Nov 06, Stephen Duncan wrote:
Can someone at least take a look at this critical issue:
http://jira.codehaus.org/browse/MCHECKSTYLE-54 and assess if a fix
could be made to be included prior to a release?
It's Joakim's call but we posted about what plugins were going
i think the id field should be apache.org
On 11/2/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
On both the trunk maven/components/pom.xml and the 2.0 branch
maven-2.0.x/pom.xml,
- the poms have minotaur.a.o when it should be people.a.o, and
- the for the site doesn't match the development proce
Could it be updated to use PMD 3.8 first? 3.7 is still very buggy with
JDK 1.5 code. 3.8 has several fixes for that.
Jira:
http://jira.codehaus.org/browse/MPMD-41
Without that, I'd be -1 (non-binding).
Also:
http://jira.codehaus.org/browse/MPMD-30
http://jira.codehaus.org/browse/MPMD-47
w
+1
On 6 Nov 06, at 9:10 AM 6 Nov 06, Joakim Erdfelt wrote:
Hi,
It has been 3 months since the last release of the maven-pmd-plugin,
Since then, there has been a refactoring of the excludes logic to
bring
harmony to the pmd and cpd reports, been numerous fixes to correct
various site
genera
+1
Thanks so much for working on these releases!
On 6 Nov 06, at 8:35 AM 6 Nov 06, Joakim Erdfelt wrote:
Hi,
It has been 5 months since the last release of the maven-checkstyle-
plugin,
Since then, there have been numerous fixes to correct various site
generation failures, updated maven rul
On 06/11/2006, at 3:13 PM, Scott Ryan wrote:
I think the best solution would be to produce a report when the
checksums
fail and allow the user to easily correct the problem in the Archiva
repository.
That's the intent. The report is already there, the mechanism to fix
from within Archiva
Yep, this would be a nice improvement to look forward to from a
usability perspective!
While I can imagine generating suggestions for GroupId values for new M1
and M2 projects being added, I am not sure how we could come up with
something similar for Shell or Ant projects.
Cheers,
Rahul
J
Can someone at least take a look at this critical issue:
http://jira.codehaus.org/browse/MCHECKSTYLE-54 and assess if a fix
could be made to be included prior to a release?
-Stephen
On 11/5/06, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
Hi,
It has been 5 months since the last release of the mav
Hi,
It has been 5 months since the last release of the maven-checkstyle-plugin,
Since then, there have been numerous fixes to correct various site
generation failures, updated maven ruleset, some cleanup of the report
layout, header refactoring, revised documentation, alignment with plugin
documen
Hi,
It has been 3 months since the last release of the maven-pmd-plugin,
Since then, there has been a refactoring of the excludes logic to bring
harmony to the pmd and cpd reports, been numerous fixes to correct various site
generation failures, updates to allow for build output of pmd violations
I see. Then a better solution would be the one presented in MWAR-58.
It uses the getClassifier method of the artifact handler.
On 11/6/06, Brett Porter <[EMAIL PROTECTED]> wrote:
The artifact handler can already take care of this by calling
getClassifier on it.
- Brett
On 06/11/2006, at 5:22 A
I'm not convinced about this. This is basically ignoring checksums in
the source repository - shouldn't we be forcing them to correct them?
I'd like to do the same thing on sync.
- Brett
On 05/11/2006, at 1:43 PM, [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Sat Nov 4 18:43:13 2006
New
On 6 Nov 06, at 6:08 AM 6 Nov 06, Brett Porter wrote:
shouldn't this be at /archiva/sandbox?
I can move them all over to being this, we currently have this:
http://svn.apache.org/repos/asf/maven/continuum/trunk/continuum-sandbox/
But it can all shift over, yes. That was what I looked at fir
On 06/11/2006, at 11:10 AM, Jason van Zyl wrote:
http://svn.apache.org/repos/asf/maven/sandbox/ssh-tester/
Yes, there is. It uses the built in descriptor, that's all.
Great, who decided having multiple ways of doing this was a good
idea? I always, by habit, look in the src/main/assembly
This seems less accurate than before. It updates snapshot
dependencies and plugins, and release metadata for both.
It'd be more accurate to say "Forces a check for updated releases and
snapshots on remote repositories"
On 05/11/2006, at 2:33 AM, [EMAIL PROTECTED] wrote:
Author: vsiveton
D
Should we put the odt somewhere that doesn't need to be deployed
every time?
- Brett
On 05/11/2006, at 12:19 AM, [EMAIL PROTECTED] wrote:
Author: vsiveton
Date: Sat Nov 4 05:19:12 2006
New Revision: 471179
URL: http://svn.apache.org/viewvc?view=rev&rev=471179
Log:
MNG-2169: Want to contrib
shouldn't this be at /archiva/sandbox?
- Brett
On 06/11/2006, at 10:25 AM, [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Sun Nov 5 15:25:53 2006
New Revision: 471566
URL: http://svn.apache.org/viewvc?view=rev&rev=471566
Log:
o adding sandbox
Added:
maven/archiva/trunk/archiva-sandbox/
The artifact handler can already take care of this by calling
getClassifier on it.
- Brett
On 06/11/2006, at 5:22 AM, [EMAIL PROTECTED] wrote:
Author: jtolentino
Date: Sun Nov 5 10:22:37 2006
New Revision: 471487
URL: http://svn.apache.org/viewvc?view=rev&rev=471487
Log:
[MWAR-59] Resoluti
http://svn.apache.org/repos/asf/maven/sandbox/ssh-tester/
Yes, there is. It uses the built in descriptor, that's all.
Great, who decided having multiple ways of doing this was a good
idea? I always, by habit, look in the src/main/assembly. That is a
bad idea allowing both ways as now we
On 04/11/2006, at 8:20 PM, Jason van Zyl wrote:
On 4 Nov 06, at 2:19 PM 4 Nov 06, Brett Porter wrote:
On 04/11/2006, at 1:17 PM, [EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewvc?view=rev&rev=471098
Log:
o create an executable JAR, assembly doesn't seem to want to let
you make
Good day to you, Stephane,
Don't quote me on this one, but i don't think there is a functionality in
maven that filters and copies file given the Resources, and the encoding
Charset. In fact, the code segment of the resource filtering of
maven-resources-plugin is practically duplicated in maven-w
John,
I saw you were touching a few things in the repository assembler and
I started decoupling it from the assembly plugin a while ago and
forgot to check it in so I've put it in the archiva-sandbox. Just a
heads up.
http://svn.apache.org/repos/asf/maven/archiva/trunk/archiva-sandbox/
a
On 5 Nov 06, at 5:13 PM 5 Nov 06, Dennis Lundberg wrote:
I've had a look at fixing MNG-2117 [1] and realized that the
"release" tags have been removed [2] from /doap_Maven.rdf. This was
done when we started to use the maven-doap-plugin to generate that
file.
Having looked at the source f
Kenney Westerhof wrote:
How is the DOAP file generated now? String concatenation?
It's using org.codehaus.plexus.util.xml.PrettyPrintXMLWriter right now.
Since everything else in the Maven project uses modello we should
stick with that, but as I understand it element attributes aren't suppor
How is the DOAP file generated now? String concatenation?
Since everything else in the Maven project uses modello we should
stick with that, but as I understand it element attributes aren't supported
that well. If we're in a hurry to get this fixed we might use JAXB
in the mean time. There's a m
I've had a look at fixing MNG-2117 [1] and realized that the "release"
tags have been removed [2] from /doap_Maven.rdf. This was done when we
started to use the maven-doap-plugin to generate that file.
Having looked at the source for the doap plugin and the format of the
"release" tags in a do
29 matches
Mail list logo
