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
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
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
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
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
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:
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 shown
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 ==
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
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
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
--
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
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
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?
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:licode1.0/code Version 1.0/li.
Also, when you think about this class by itself, we are testing a range.
How maven decides to handle
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..
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 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
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.
resources
!-- Include the apache
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:
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
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
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:
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
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:
+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.
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
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,
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
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
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,
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
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.
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
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
+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
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
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:
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
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
+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
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
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
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
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:
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
+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
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 generation
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.
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,
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:
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 should
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
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 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
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:
Hi,
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:
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
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
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
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 going
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
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
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
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]
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
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
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,
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
69 matches
Mail list logo
