+1
Emmanuel
Brian E. Fox a écrit :
I'd like to release maven-dependency-plugin:2.0-alpha-2
Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-dependency-plug
in-2.0-alpha-2/
Staged at:
http://people.apache.org/~brianf/staging-repository
Changes:
http://jira.codehaus.org/secure/Rel
+1
On 12 Mar 07, at 8:28 PM 12 Mar 07, Brian E. Fox wrote:
I'd like to release maven-dependency-plugin:2.0-alpha-2
Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-dependency-
plug
in-2.0-alpha-2/
Staged at:
http://people.apache.org/~brianf/staging-repository
Changes:
http://j
On 12 Mar 07, at 4:12 PM 12 Mar 07, Brett Porter wrote:
On 12/03/2007, at 4:03 PM, Jason van Zyl wrote:
On 12 Mar 07, at 3:31 PM 12 Mar 07, Brett Porter wrote:
should download.apt be removed from svn if it is generated?
Probably better to leave it there as people updating might forget
+1 no regression problem from my side
-D
On 3/12/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
I'd like to release maven-dependency-plugin:2.0-alpha-2
Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-dependency-plug
in-2.0-alpha-2/
Staged at:
http://people.apache.org/~brianf/stag
+1
On 10/03/2007, at 3:21 PM, Dennis Lundberg wrote:
Hi,
Trying this vote once more. This with staging.
This release is a preparation for a release of the maven-one-plugin.
The issues that have been resolved can be seen in JIRA:
http://jira.codehaus.org/browse/MNG-2320
http://jira.codehaus.o
+1
On 10/03/2007, at 3:25 PM, Dennis Lundberg wrote:
Hi,
Trying this vote once more. This time with staging.
This release is a preparation for a new release of the maven-plugin-
plugin.
Changes:
- Add support for new annotations: @since for mojos and
@implementation
for parameters
- Rem
http://maven.apache.org/developers/maven-eclipse-codestyle.xml
seems to be out of date ( the throws, extend, etc do not split )
Do we have another official one?
Thanks
-D
Good day to you, Wendy,
On Windows XP, Maven 2.0.5, maven-source-plugin -r517268 builds fine
Cheers,
Franz
On 3/12/07, Wendy Smoak <[EMAIL PROTECTED]> wrote:
I'm seeing test failures in maven-source-plugin. Anyone else?
On Windows w/ Maven 2.0.5:
Failed tests:
testProject003(org.apache.ma
Interesting...
http://people.apache.org/~wsmoak/maven/archiva/r517480-proxying-index-page.jpg
That's Archiva running on localhost, proxying central, and when I visit
http://localhost:9091/archiva/repository/myrepo/org/apache/maven/plugins/maven-dependency-plugin
I see the index page from central
I'm seeing test failures in maven-source-plugin. Anyone else?
On Windows w/ Maven 2.0.5:
Failed tests:
testProject003(org.apache.maven.plugin.source.SourceJarMojoTest)
testProject007(org.apache.maven.plugin.source.SourceJarMojoTest)
testProject004(org.apache.maven.plugin.source.TestSourceJar
I'd like to release maven-dependency-plugin:2.0-alpha-2
Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-dependency-plug
in-2.0-alpha-2/
Staged at:
http://people.apache.org/~brianf/staging-repository
Changes:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13137&styleName
=
Is this going to result in a copy of all the artifacts with added
bundled metadata?
Will the structure will be same? Just wondering if the bundles should
just be included in the main repository with a classifier.
- Brett
On 12/03/2007, at 4:46 PM, Carlos Sanchez wrote:
There are some ini
There are some initiatives like Apache Felix about repackaging
libraries from the maven repository until projects themselves include
the OSGi manifest.
It makes sense in the meantime to have a Maven repo with same
structure but with OSGi bundles. This repo would be temporal and
things could chang
Hi,
I didn't get an answer from the maven users alias. Could someone here
answer this.
Maven classpath generation seems not to follow any order. Shouldn't it
use the same order depedencies are mentioned in the pom file.
Somewhere I read Maven 2.0.5 fixed this issue, but when I tested it
doesn't
On 12/03/2007, at 4:03 PM, Jason van Zyl wrote:
On 12 Mar 07, at 3:31 PM 12 Mar 07, Brett Porter wrote:
should download.apt be removed from svn if it is generated?
Probably better to leave it there as people updating might forget
to generate it and deploy the site and then we'll end up
On 12 Mar 07, at 3:31 PM 12 Mar 07, Brett Porter wrote:
should download.apt be removed from svn if it is generated?
Probably better to leave it there as people updating might forget to
generate it and deploy the site and then we'll end up with an empty
page. We can just nuke it when Velo
I wonder if this is an OS thing? I've heard that before, but when I
experimented with dependency:build-classpath, it was always ordered the
same.
-Original Message-
From: Jagan Padmanabha Pillai -X (jpadmana - Insight Solutions, Inc. at
Cisco) [mailto:[EMAIL PROTECTED]
Sent: Monday, March
should download.apt be removed from svn if it is generated?
On 12/03/2007, at 3:29 PM, [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Mon Mar 12 15:29:43 2007
New Revision: 517432
URL: http://svn.apache.org/viewvc?view=rev&rev=517432
Log:
o fix the generation script and "encourage" is spelt li
On 12 Mar 07, at 10:06 AM 12 Mar 07, Brian E. Fox wrote:
I think what he is saying is that plugins out there may declare a
newer
version of p-u (like mdep) that tested to work with that version ok
(so
we thought) because it was really using the mvn core version. If
suddenly you allow plugin
+1. I've been running a snapshot rev from around sept, an official
version would be handy.
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Monday, March 12, 2007 1:17 PM
To: dev@maven.apache.org
Subject: PMD plugin remaining issues...
As you probably saw on the com
As you probably saw on the commit list, I did a bunch of commits for PMD
over the weekend. At this point, there is only one remaining issue open
for 2.2. (MPMD-41) To fix that completely, I need part of the objectweb
m2 repository synced to central. (asm/**/*)I've included the
current
I think what he is saying is that plugins out there may declare a newer
version of p-u (like mdep) that tested to work with that version ok (so
we thought) because it was really using the mvn core version. If
suddenly you allow plugins to use their own declared versions, they may
suddenly not work.
Dennis,
On Monday 12 March 2007 12:04, Dennis Lundberg wrote:
> I stumbled upon this issue over the weekend. If you are using the trunk
> version from svn of the Checkstyle plugin, you cannot build the site for
> any of our own plugins. I managed to work around it by explicitly
> specifying maven
Arnaud HERITIER wrote:
On 3/5/07, Brett Porter <[EMAIL PROTECTED]> wrote:
On 04/03/2007, at 4:05 PM, Dennis Lundberg wrote:
> I found a couple of other bugs while testing, that I also fixed. I
> feel pretty much done now. Snapshots have been deployed so that'll
> give it some testing.
cool,
I stumbled upon this issue over the weekend. If you are using the trunk
version from svn of the Checkstyle plugin, you cannot build the site for
any of our own plugins. I managed to work around it by explicitly
specifying maven-checkstyle-plugin version 2.1 temporarily in the pom. I
got the sam
On 12 Mar 07, at 6:15 AM 12 Mar 07, Jerome Lacoste wrote:
On 3/12/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
I think we should require the hiding of p-u 1.4.1 in 2.0.6, or let
it still use 1.1. All previous releases (except for beta releases)
use p-u 1.1. I'm afraid exposing p-u 1.4.1 wi
On 12 Mar 07, at 2:23 AM 12 Mar 07, Kenney Westerhof wrote:
I think we should require the hiding of p-u 1.4.1 in 2.0.6, or let
it still use 1.1. All previous releases (except for beta releases)
use p-u 1.1. I'm afraid exposing p-u 1.4.1 will break more
than just surefire.
I certainly do the h
Yes, I can add the override model option in; I'm fairly busy presently, but
I can hopefully have something out in the next day or two.
Patrick
On 3/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 11 Mar 07, at 4:02 PM 11 Mar 07, Ralph Goers wrote:
> Jason,
>
> Well, I view the behavior o
On 3/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: jvanzyl
Date: Sun Mar 11 09:27:08 2007
New Revision: 516945
URL: http://svn.apache.org/viewvc?view=rev&rev=516945
Log:
o little script to swap in the versions, until the site plugin can do it, this
will do. i'm tired of changing N
On 3/12/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
The runtime works fine there. Check your core directory. Do you have
plexus-component-api-1.0-alpha-18.jar,
plexus-container-default-1.0-alpha-18.jar and
plexus-appserver-host-2.0-alpha-8-SNAPSHOT.jar ?
I have:
[EMAIL PROTECTED] /cygdr
On Mon, March 12, 2007 4:34 pm, Graham Leggett wrote:
> Has anyone seen release:perform work with a classifier present?
I have managed to narrow this down to the deploy plugin. It seems the
deploy plugin cannot deploy a jar with a classifier. The stacktrace is
below.
[INFO] [jar:jar]
[INFO] Buil
Jason,
Back in December, you changed a bunch of plugins (PMD and Checkstyle are
definitely two of them) to use the ResourceManager instead of the custom
Locator code they had.
That seems to work fine when the plugins are part of the actual build
build, but not during a reporting run.If t
I don't know how you can get alpha-19-SNAPSHOT, but I added
plexus-component-api in archiva-plexus-runtime so it should be ok now.
Emmanuel
Wendy Smoak a écrit :
On 3/12/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
The runtime works fine there. Check your core directory. Do you have
plexus
Quick updates:
1) It's definitely the classloader. If a set the contextClassLoader to
the classloader of the plugin, the RM works fine. That seems like less of
a hack so I'll go with that.
2) I THINK this is the cause of MCHECKSTYLE-65. I'll try the classloader
thing there too.
Dan
Hi all,
I am trying to do a release:perform on a project that creates a jar with a
classifier.
For some reason, as part of release:perform, install:install is called,
and when install:install is called _without_ being part of the build
lifecycle, it fails with the error below.
I tried configurin
On 3/12/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
I think we should require the hiding of p-u 1.4.1 in 2.0.6, or let
it still use 1.1. All previous releases (except for beta releases)
use p-u 1.1. I'm afraid exposing p-u 1.4.1 will break more
than just surefire.
I agree.
But even hidin
The runtime works fine there. Check your core directory. Do you have
plexus-component-api-1.0-alpha-18.jar,
plexus-container-default-1.0-alpha-18.jar and
plexus-appserver-host-2.0-alpha-8-SNAPSHOT.jar ?
Emmanuel
Brett Porter a écrit :
Emmanuel last changed the container - anything to do wit
There is a mismatch of plexus component api and container-default by
the looks of things, unless there is some code in archiva that uses
the removed getComponentKey() method.
Andy
On 11 Mar 2007, at 20:04, Wendy Smoak wrote:
On 3/11/07, Brett Porter <[EMAIL PROTECTED]> wrote:
This occurs
Oups,
I forgotten to say that archetypes is the first foot a developper starts for
using maven.
This is why i'm concerned about archetypes.
I also see archetypes a examples of using maven (for example the axistools)
Raphaël
2007/3/12, Raphaël Piéroni <[EMAIL PROTECTED]>:
My current task is no
My current task is now to document what i have done so far.
Answers and questions inlined.
Raphaël
2007/3/12, Brett Porter <[EMAIL PROTECTED]>:
My basic feedback would be similar to Jason's.
Key requirements:
- backwards compatibility with existing archetypes is a definite
requirement
Is
I think we should require the hiding of p-u 1.4.1 in 2.0.6, or let
it still use 1.1. All previous releases (except for beta releases)
use p-u 1.1. I'm afraid exposing p-u 1.4.1 will break more
than just surefire.
Jason van Zyl wrote:
On 12 Mar 07, at 12:22 AM 12 Mar 07, Jerome Lacoste wrote:
It is indeed similar but Erik's thing will build it against *all*
compatible versions, where compatible means within major upgrades (a
x.y.z pattern is assumed).
--
Trygve
Jesse McConnell wrote:
erik
I saw this issue and thought of you :)
http://jira.codehaus.org/browse/CONTINUUM-45
jesse
Jesse McConnell wrote:
sounds good to me, imo either trunc it or maybe switch the model over
to a clob for that in the db...
I tried to make it a CLOB once but couldn't get it to work because of
some JPOX issues IIRC so for alpha-1 just chop the exception and/or
write it to a separate file an
Jesse McConnell wrote:
I have gone through jira issues there were assigned to 1.1 and spread
things out a bit.
here is my criteria I used in separating out the issues:
1.1-alpha-1 -> issues that need to be addressed asap before we pull
any kinda alpha
1.1-alpha-2 -> higher importance issues and
44 matches
Mail list logo
