Thanks a lot emmanuel,
Now the release plugin don't complain because of a missing dependency.
I still have trouble with release:perform when using a CVS repository and an
ext provider. Looks like the release plugin is trying to use a java provider,
instead of an ext command, which knows of my
Just a user here, but definitly a +1.
Dependency version resolution should always stay tuned to the POM of the
current project being built.
Denis.
> -Message d'origine-
> De : Emmanuel Venisse [mailto:[EMAIL PROTECTED]
> Envoyé : vendredi 16 mars 2007 08:12
> À : Maven Developers List
ok, we need it :( it is called by a component in maven deps.
Emmanuel
Emmanuel Venisse a écrit :
I don't misunderstand.
I just say that the component declared in maven dep is with 'maven'
role-hint and we need to use it instead of re-declaring the component.
I'll revert your patch.
We'll use
I don't misunderstand.
I just say that the component declared in maven dep is with 'maven' role-hint
and we need to use it instead of re-declaring the component.
I'll revert your patch.
We'll use the 'default' role-hint when we'll use the latest maven-project.
Emmanuel
Andrew Williams a écrit :
On 16 Mar 07, at 12:10 AM 16 Mar 07, Ralph Goers wrote:
Question. Has Mike or Patrick updated the documentation yet? I
started to update the wiki a couple of months ago but put it off as
I didn't want the wiki to reflect something that you couldn't yet
use. Plus the behavior changed sli
+1
Emmanuel
Jason van Zyl a écrit :
Hi,
After working with it a little this week I would like to propose to make
MNG-1577 behavior introduced the default. Builds are completely and
totally unpredictable without this behavior. The behavior in 2.0.5 is
fundamentally broken. To are totally pre
I need one more vote...
--
Dennis Lundberg
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 paramete
What needs to be done to get these published? I commented on the
issue regarding the dependencies. I'm not 100% sure what the full
dependencies are for these... and I'd rather not guess.
--jason
On Mar 15, 2007, at 9:51 PM, Carlos Sanchez wrote:
i'm keeping an eye on it
On 3/15/07, Jas
I started to edit it but didn't save it. The page that really needs to
be updated is
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html.
However, I believe the page I was editing is at
http://docs.codehaus.org/display/MAVENUSER/Dependency+Mechanism.
To edit
i'm keeping an eye on it
On 3/15/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
Can someone with central repo skillz please help get the full mx4j
3.0.2 release published to central:
http://jira.codehaus.org/browse/MAVENUPLOAD-1220
The Geronimo 1.2 release is blocked waiting for some mx4j 3.
We haven't done any documentation yet, no. I'll certainly be happy to write
some up, help you out, review what you have, etc.
Where is the wiki page you were editing? Is it open to anyone, or do I need
to submit changes to it through you or Mike?
On 3/15/07, Ralph Goers <[EMAIL PROTECTED]> wro
Question. Has Mike or Patrick updated the documentation yet? I started
to update the wiki a couple of months ago but put it off as I didn't
want the wiki to reflect something that you couldn't yet use. Plus the
behavior changed slightly since then.
If they haven't beaten me to it, I'd be ha
Well, obviously I would have no objection. ;-)
+1
Ralph
Jason van Zyl wrote:
Hi,
After working with it a little this week I would like to propose to
make MNG-1577 behavior introduced the default. Builds are completely
and totally unpredictable without this behavior. The behavior in 2.0.5
i
Can someone with central repo skillz please help get the full mx4j
3.0.2 release published to central:
http://jira.codehaus.org/browse/MAVENUPLOAD-1220
The Geronimo 1.2 release is blocked waiting for some mx4j 3.0.2
artifacts to be published (only one of the artifacts for this release
I can attest to this being a major issue for complex builds. Without
this behavior, it's nearly impossible to manage the build of complex
projects.
-Nathan
On 3/15/07, Mike Perham <[EMAIL PROTECTED]> wrote:
A will get D 2.0. Yes, our build depends heavily on this behavior.
I'm ok with it goin
Issue Subscription
Filter: Design & Best Practices (37 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
htt
A will get D 2.0. Yes, our build depends heavily on this behavior.
I'm ok with it going into 2.0.6 as long as it is noted in the release
notes. Based on the number of votes the issue has, this is a major
problem for a lot of people. I can't imagine any reasonably sized
build which has not enco
You misunderstand it's purpose.
I am not defining a dependency, but rather re-declaring the component.
That is a copy of the "maven" hinted component as "default". The
latest maven-project uses "default" so this is a temporary measure.
Does that make sense?
Andy
On 15 Mar 2007, at 22:41, Emma
Dennis,
Can you give it another try? I think I understand what's happening with
the ResourceManager now and it should work.
Dan
On Thursday 15 March 2007 18:21, Dennis Lundberg wrote:
> Daniel,
>
> I can't get the trunk for the Checkstyle plugin to work. Downgrading
> to a previous release
I have 3 binding (Jason, Emmanuel, Stephane) and 3 user votes, no -1.
The vote succeeds and I'll start moving to the public repo.
Thanks,
-Brian
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Monday, March 12, 2007 11:29 PM
To: Maven Developers List
Subject: [VOTE]
i'm fine for 2.1, for 2.0.6 may be too risky
What about this use case for transitive dependencyManagement? has been tested?
A -> B -> C -> D
C depends on D 1.0
B has D 2.0 in dependencyManagement, no D in dependencies
A should get D 2.0
On 3/15/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
I can think of some cases where it might break a build, but most of them
are where a transitive dependency creeps into a build because the user
assumes that MNG-1577 is how it's always worked. That being said, these
issues would be easily remedied since you now have more control, and
anyone using d
Hi,
After working with it a little this week I would like to propose to
make MNG-1577 behavior introduced the default. Builds are completely
and totally unpredictable without this behavior. The behavior in
2.0.5 is fundamentally broken. To are totally prey to any dependency
introduced by
I'm withdrawing this vote. While debugging the checkstyle plugin, I
discovered a similar situation in which rulesets defined by URL would
have worked with 2.1, but not with 2.2. That's a serious regression so
I'm withdrawing this vote to get that fixed. I'll re-spin the build
tomorrow and
Ok. eclipse:eclipse -DdownloadSources=true to the rescue. :-)
Seriously, it looks like the ResourceManager has to be manually
configured with "acceptable" paths to look at. Thus, if I add:
locator.addSearchPath( "url", "" );
then the URL form works fine. I personally thing ""
The latest version might be incompatible. I was having test failures
last time I built it. I would suggest checking out the tag for the last
release and adding your code to that.
-Original Message-
From: Hartwell, Tom [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 7:03 PM
To: de
On 15 Mar 07, at 6:42 PM 15 Mar 07, Brian E. Fox wrote:
They use the plugin, but are not testing the plugin directly. They are
testing an issue in maven-project.
Cool, thanks for clarifying.
Jason.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Thursday, Ma
Hello, if this is a redundant question please refer me to a thread that
has covered it. I searched through the last 3 months of the mail
archive w/ no luck.
I checked out the maven-assembly-plugin in order to add a piece of
functionality. It built fine, and installed into my local .m2 repo.
B
On Thursday 15 March 2007 18:21, Dennis Lundberg wrote:
> Daniel,
>
> I can't get the trunk for the Checkstyle plugin to work. Downgrading
> to a previous release like 2.1 or 2.0 works though.
Ack.. This is a different but related issue. The ResourceManager that
is injected during site generat
+1
Emmanuel
Dennis Lundberg a écrit :
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.org/browse/MNG-2
They use the plugin, but are not testing the plugin directly. They are
testing an issue in maven-project.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 5:44 PM
To: dev@maven.apache.org
Subject: Re: svn commit: r518445 - in
/maven/core-int
Handy,
I think this patch is wrong, we need to use this component with 'maven'
role-hint because it's this component declared in maven-project.
Emmanuel
[EMAIL PROTECTED] a écrit :
Author: handyande
Date: Tue Mar 6 17:17:11 2007
New Revision: 515406
URL: http://svn.apache.org/viewvc?view=re
I need one more vote...
--
Dennis Lundberg
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://j
On Mar 15, 2007, at 2:51 PM, Daniel Kulp wrote:
Joakim,
The "current" practice (always subject to change at apache) is to use
version numbers with incubator or incubating in the name. For
example:
2.0-incubator-M2
There has been talks about using a groupId, but the general
consensus has
Hi,
When i call a mojo i have with -DgroupId=XX, i got a validation error
on a dependent pom. when i run -DgroupIdX=XX, i got my result.
I have the same result defining a groupId parameter or not in the mojo.
And i also have the same result when call in the mojo in a project's
dir on in an empt
+1
On 15 Mar 07, at 5:14 PM 15 Mar 07, Brian E. Fox wrote:
+1 we can't reproduce the initial errors and everything looks good.
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 3:42 PM
To: Maven Developers List
Subject: RE: [VOTE] Release Ma
Daniel,
I can't get the trunk for the Checkstyle plugin to work. Downgrading to
a previous release like 2.1 or 2.0 works though.
Daniel Kulp wrote:
Brian,
Two things to try:
1) Remove your local copy of the checkstyle plugin and force it to
re-download.
2) Rebuild checkstyle based on t
Joakim,
The "current" practice (always subject to change at apache) is to use
version numbers with incubator or incubating in the name. For example:
2.0-incubator-M2
There has been talks about using a groupId, but the general consensus has
been that if it's in the version, it's unnecessary a
Are these integration tests that use the MDEP plugin? Don't put them
in the ITs if they are plugin specific.
We need to stop using production plugins in the ITs.
Jason.
On 14 Mar 07, at 10:34 PM 14 Mar 07, [EMAIL PROTECTED] wrote:
Author: brianf
Date: Wed Mar 14 19:34:52 2007
New Revision:
One question I have ...
Do you want to identify the incubating projects on central in any way?
A groupId prefix of org.apache.incubating.* for example?
- Joakim
Daniel Kulp wrote:
> Just to let everyone know, there is a long thread about the incubator M2
> repository on general@incubator.apache
+1 we can't reproduce the initial errors and everything looks good.
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 3:42 PM
To: Maven Developers List
Subject: RE: [VOTE] Release Maven PMD Plugin 2.2
We are having trouble with the failurePri
Just to let everyone know, there is a long thread about the incubator M2
repository on general@incubator.apache.org:
http://mail-archives.apache.org/mod_mbox/incubator-general/200703.mbox/<31cc37360703140920h6a601b57gbb86ff0cd5e8049b%40mail.gmail.com>
Since this affects Maven users as well as p
We are having trouble with the failurePriority in this version. We have
been running a snapshot from when I added that feature. Do you know if
anything changed?
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 11:20 AM
To: Maven Developers Lis
I'd really like to see this as well, I just don't have the time to start
looking at it and learning that code right now. :-( It's a much
bigger chunk of code than the plugins I've been working on.
About 1/2 of the projects I'm looking at use the 2.2-SNAPSHOT version due
to bugs in 2.1.
I mirrored a repository, and from what I can see a lot of the
non-snapshot version directories have
the maven-metadata.xml as well.
Also, since the snapshot version is contained in maven-metadata.xml in
at the artifactId level, should we
be duplicating it at the version level? After all the sa
yes, you are also correct on that, great point
On 3/15/07, Thierry Lach <[EMAIL PROTECTED]> wrote:
Of the unresolved issues for 1.1-alpha-any, 108 of them are against some
version of continuum 1.0 and might not apply to continuum-1.1, but someone
is going to have to verify that.
On 3/13/07, Bre
On Mar 15, 2007, at 2:38 AM, Kenney Westerhof wrote:
Jason Dillon wrote:
How does a test repository help? I still need to configure in my
src/it/*/pom.xml the version of the plugin I'm testing.
The latest plugin will be used, which is usually what you're testing.
If the test repository does
It's only available in snapshot version directories and contains a list of all
the snapshot versions there and names the latest version. So it's useful for
snapshots.
Ole Ersoy wrote:
Hi,
Just wondering if there is a purpose to having maven-metadata.xml in the
version directories (The direct
Hi,
Just wondering if there is a purpose to having maven-metadata.xml in the
version directories (The directories that also contain the pom for the
project) of the maven repository?
Thanks,
- Ole
-
To unsubscribe, e-mail
Of the unresolved issues for 1.1-alpha-any, 108 of them are against some
version of continuum 1.0 and might not apply to continuum-1.1, but someone
is going to have to verify that.
On 3/13/07, Brett Porter <[EMAIL PROTECTED]> wrote:
On 12/03/2007, at 7:35 AM, Jesse McConnell wrote:
On 13/03/2
+1
On 3/15/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:
I'd like to release version 2.2 of the PMD plugin. It's been over 8
months since the last release and this is a fairly significant
improvement addressing 14 JIRA items.
---
I've posted a patch to JIRA that enables (at least for me, using postgres
8.1) running continuum against postgres using the built-in jetty. It should
be very simple to add support for a different version of postgres also by
cloning the profile.
On 3/15/07, Thierry Lach <[EMAIL PROTECTED]> wrote:
I deployed a new version of maven-scm-provider-cvsjava without the uppercase,
sorry.
Emmanuel
Cabasson Denis a écrit :
Hi folks!
Having trouble with today's version of maven-release plugin.
Looks like maven-release-manager depends on maven-scm-provider-cvsjava, while the deployed version is
OK, it seems to be something that JBoss is doing to get in the way. I used
the instructions at
http://docs.codehaus.org/display/CONTINUUM/Database+Configuration (with the
8.1 jdbc jar) and was able to get Continuum up and running using jetty.
On 3/14/07, Jesse McConnell <[EMAIL PROTECTED]> wrote
check http://wiki.apache.org/general/SummerOfCode2007
On 3/15/07, Isuru Suriarachchi <[EMAIL PROTECTED]> wrote:
Hi all,
I'm an undergraduate student of the Computer Science and Engineering
department at University of Moratuwa, Sri Lnaka. I'm interested in doing a
project on Apache/maven for the
Hi folks!
Having trouble with today's version of maven-release plugin.
Looks like maven-release-manager depends on maven-scm-provider-cvsjava, while
the deployed version is named maven-scm-provider-cvsJava (upper case j).
Isn't that a bug of some sort?
Cheers.
Denis.
> -Message d'origin
I'd like to release version 2.2 of the PMD plugin. It's been over 8
months since the last release and this is a fairly significant
improvement addressing 14 JIRA items.
Staging area:
http://people.apache.org/~dkulp/stage_pmd/
Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-p
Brian,
You can see what happens just by running:
mvn -Prelease package
then look at whats in the jars.
On Wednesday 14 March 2007 20:16, Brian E. Fox wrote:
> So I can remove this code from my pom then:
Correct, shouldn't be needed.
>
>
>
>
I applied it, it seems to be good but can't test it, I don't have Clearcase.
I'll deploy a new maven-scm SNAPSHOT today.
Emmanuel
ArneD a écrit :
Hi Emmanuel and others,
I implemented the above mentioned feature. Please have a look at the patch,
and apply it. If you apply it, it would be grea
Hi Emmanuel and others,
I implemented the above mentioned feature. Please have a look at the patch,
and apply it. If you apply it, it would be great if you could deploy a new
maven-scm SNAPSHOT version to the apache snapshots repository as well.
http://jira.codehaus.org/browse/SCM-287
Thanks
-
I think it makes more sense to let 2.0.5 mean [2.0.5,), not [2.0.5].
If you'd do the latter we'd definitely have a problem. There are lots of
places where maven-model 2.0 is used, and also lots of places where 2.0.3 or
later
is used. Having this restriction will cause maven's build to fail..
So
I'll try doing that. Strictly speaking though, I think the only thing
that makes sense is 2.0.5 = [2.0.5]. In fact, the javadoc for
createFromVersionSpec says this:1.0 Version 1.0.
Also, when you think about this class by itself, we are testing a range.
How maven decides to handle the results of th
Personally I believe a release is needed ASAP. Users should not use
SNAPSHOTs and no releases work anymore.
On 3/15/07, Vincent Massol <[EMAIL PROTECTED]> wrote:
Hi Mike,
Clover plugin 2.4-SNAPSHOT has a license valid till 30th of January
2008.
Maybe this warrants a release of the plugin?
Hi Mike,
Clover plugin 2.4-SNAPSHOT has a license valid till 30th of January
2008.
Maybe this warrants a release of the plugin?
http://jira.codehaus.org/browse/MCLOVER?
report=com.atlassian.jira.plugin.system.project:roadmap-panel
Thanks
-Vincent
On Mar 8, 2007, at 4:53 PM, Mike Perham w
Hi all,
I'm using the maven-war-plugin to generate a war file before the
maven test phase, but the cobertura-maven-plugin change the
classesDirectory to instrument the code and the war plugin don't allow
this. There is any way to make the parameter classesDirectory
overridable?
I'm using t
Hi guys,
Is there any possibility I can prod you for a release of
maven-assembly-plugin 2.2? As far as I can tell, all the SNAPSHOTs it
depends on have now been released, it fixes about a bazillion bugs, and
the docs on the site have referred to the SNAPSHOT for ages.
Cheers,
Richard
--
Ri
Brian E. Fox wrote:
Well, I made the change and all the IT tests pass. I'm not surprised because
when I searched for the use of that VersionRange.contains() it's only used in
one place, so it's entirely likely this is not working and no one noticed.
It could very well be that there's no it
Stephane Nicoll wrote:
I don't think so. sources and ear are for sure good candidates since I
wrote those tests. At some point, we decided to use that testing
technique and fix remaining issues (namely the local repo first
install story).
We need to discuss this because I'd like to work on the
Well, I made the change and all the IT tests pass. I'm not surprised because
when I searched for the use of that VersionRange.contains() it's only used in
one place, so it's entirely likely this is not working and no one noticed.
It's easy to tweak my patch so that contains treats "2.0.5" == "[2
Brian E. Fox wrote:
The problem is that I assumed "2.0.5" == "[2.0.5,)". I can understand how it is when I
see it and I can work with that. The problem now is that createFromVersionSpec doesn't create any
restrictions and restrictions.contains returns true by default. If I add the test as sho
The problem is that I assumed "2.0.5" == "[2.0.5,)". I can understand how it is
when I see it and I can work with that. The problem now is that
createFromVersionSpec doesn't create any restrictions and restrictions.contains
returns true by default. If I add the test as shown below, it fails here
Wendy Smoak wrote:
On 3/14/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
The problem is that it uses the Verifier to test.
The Verifier uses the plugin from the local repo, not the current
project.
First, mvn clean install -Dmaven.test.skip=true, then mvn test and
it'll work.
I noticed th
I'm sorry, what is the problem exactly?
createFromVersionSpec: treats version as a version range, so 2.0.5 is treated
as [2.0.5,).
createFromVersion: treats version as a single pinned version, so 2.0.5 is
treated
as [2.0.5].
So, createFromVersionSpec("2.0.5").containsVersion( new
DefaultArtif
Jason Dillon wrote:
How does a test repository help? I still need to configure in my
src/it/*/pom.xml the version of the plugin I'm testing.
The latest plugin will be used, which is usually what you're testing.
If the test repository does not contain other versions of the plugin,
the one you
Hi all,
I'm an undergraduate student of the Computer Science and Engineering
department at University of Moratuwa, Sri Lnaka. I'm interested in doing a
project on Apache/maven for the Google Summer of Code 2007 competition.
Currently I'm working as an intern at WSO2 (www.wso2.org) for my industr
I don't think so. sources and ear are for sure good candidates since I
wrote those tests. At some point, we decided to use that testing
technique and fix remaining issues (namely the local repo first
install story).
We need to discuss this because I'd like to work on the WAR plugin but
I want mor
76 matches
Mail list logo