A huge nonbinding +1 from me...
Wayne
On 2/7/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
+1 (this is sorely needed)
- Joakim
Stephane Nicoll wrote:
> Hi,
>
> This release fixes all known issues, only two feature requests are
> still open and we need to discuss this a bit more, see also[1]
>
No, we have many Maven 1 based projects. We have wanted to move to Maven
2 but cannot until MNG-1577 is applied. I've actually waded through
quite a bit of the code in both versions.
Version 1.3 of the Cobertura plugin also uses Cobertura 1.8 so I guess
there must be something blatantly wrong
Issue Subscription
Filter: Outstanding Repository Maintenance: Uploads (21 issues)
Subscriber: mavendevlist
Key Summary
MAVENUPLOAD-1372hibernate 3.2.2.ga
http://jira.codehaus.org/browse/MAVENUPLOAD-1372
MAVENUPLOAD-1337Upload of latest Findbugs (v. 1.1.3) artifacts to ibiblio
Issue Subscription
Filter: Outstanding Repository Maintenance: Evangelism (40 issues)
Subscriber: mavendevlist
Key Summary
MEV-498 javax.xml.ws:jaxws-api:2.1 is bad
http://jira.codehaus.org/browse/MEV-498
MEV-36 Exo POM(s) missing dependency versions
http:
+1 (this is sorely needed)
- Joakim
Stephane Nicoll wrote:
> Hi,
>
> This release fixes all known issues, only two feature requests are
> still open and we need to discuss this a bit more, see also[1]
>
> Revision: 504652
>
> Release Notes - Maven 2.x Ejb Plugin - Version 2.1 [2]
>
> ** Bug
>
Hi,
Actually if you just put the following in a profiles.xml in the
project that uses the EJB plugin you should not have to do anything
else:
profiles.xml
---
stage
maven-ejb-plugin-stage
Maven EJB Plugin Stage
default
In my case I think I got it with V2.0 of the plugin as well. One possibility
is the way I programmed my plugin. The surefire on appears to fork off a new
process to run tests. Mine does not. Reading through the cobertura doco I
found a comment saying that cobertrua does not write the log file unt
Hi,
If you want to test this release, just add the following profile in
your settings.xm temporarily and run mvn -Pejb-staging -U:
ejb-staging
Ejb plugin staging repository
http://people.apache.org/~snicoll/maven-staging/repo/
false
Cheers,
+1
Now as an aside how do we make this easy for people to try. Included
with the vote it would be nice to provide a snippet which configures
a repository which makes the plugin usable. I'm sure we could
generate this.
Jason.
On 7 Feb 07, at 2:20 PM 7 Feb 07, Stephane Nicoll wrote:
Hi,
For some reason, I thought he hadn't incorporated the branching bit.
I see it now... (I was looking under the 'original' process before,
doh).
I'll double check this matches what he has. Sorry Joakim.
On 08/02/2007, at 8:04 AM, Barrie Treloar wrote:
On 2/8/07, Brett Porter <[EMAIL PROTECTE
On 2/8/07, Brett Porter <[EMAIL PROTECTED]> wrote:
Hi,
Just off the top of my head, but didn't want to forget about it. Now
that we stage, it seems a bit strange to tag the final release before
pushing it up. Does the below seem like a sensible amendment to the
previously discussed process?
rel
I thought you were using Maven 2. The Maven 2 plugin v2.1 uses Cobertura
1.8 which exhibits this problem. By downgrading the plugin to v2.0, you use
v1.7 of Cobertura which does not have this problem.
- Original Message -
From: "Ralph Goers" <[EMAIL PROTECTED]>
To: "Maven Developers
Hi,
Just off the top of my head, but didn't want to forget about it. Now
that we stage, it seems a bit strange to tag the final release before
pushing it up. Does the below seem like a sensible amendment to the
previously discussed process?
release:prepare:
- branch code
- checkout branch
Hi,
This release fixes all known issues, only two feature requests are
still open and we need to discuss this a bit more, see also[1]
Revision: 504652
Release Notes - Maven 2.x Ejb Plugin - Version 2.1 [2]
** Bug
* [MEJB-7] - Transitive Classpath not written to the manifest
* [MEJB-12] -
On 08/02/2007, at 5:57 AM, Jason van Zyl wrote:
Can't you "release" them to a fake repository?
I don't think it matters really. We'll try a couple things, if it
doesn't work we'll release them again and no one will reference the
old stuff.
Sound like famous last words when diddling wi
On 7 Feb 07, at 1:20 PM 7 Feb 07, Brett Porter wrote:
On 08/02/2007, at 4:58 AM, Jason van Zyl wrote:
Hi,
Stephane and I are going to try out the new POMs but in order to
do that we need to release them. So I'm going to release them, and
we'll try them so if there's something wrong we'll
On 08/02/2007, at 4:58 AM, Jason van Zyl wrote:
Hi,
Stephane and I are going to try out the new POMs but in order to do
that we need to release them. So I'm going to release them, and
we'll try them so if there's something wrong we'll release them again.
Can't you "release" them to a fake
Hi,
Stephane and I are going to try out the new POMs but in order to do
that we need to release them. So I'm going to release them, and we'll
try them so if there's something wrong we'll release them again. I
think this is an indication that profiles for releasing stuff should
not be in p
Good day
> 2. I've found some interesting components in plexus (plexus-util)
> so I get
> frustrated not getting a better documentation about what plexus can
> offer.
> Is there some plan to get better doc ?
Ask on the Plexus list but Rahul has consistently been working on it.
> How do you exp
On 7 Feb 07, at 10:22 AM 7 Feb 07, nicolas de loof wrote:
Hi guys,
Just some generic questions about maven development and Plaexus :
Plexus / Wagon and other technologies used by maven seems to re-
invent the
wheel, compared to existing projects (spring or pico, commons-vfs...)
Plexus ex
Hi guys,
Just some generic questions about maven development and Plaexus :
Plexus / Wagon and other technologies used by maven seems to re-invent the
wheel, compared to existing projects (spring or pico, commons-vfs...)
1. Do maven developers hate code created elsewhere ;-) ? as documentation
What is this well known problem. I tried upgrading the plugin for maven
1.0.2 from version 1.1.1 of cobertura to 1.3 and have the same problem -
all the reports show 0 coverage.
Ralph
Bob Allison wrote:
Sounds like the well-known Cobertura 2.1 problem. Try explicitly
specifying version 2.0 o
I think that the local repo needs to be make canonical when
initialized (from settings.xml or from system property), should fix
the bulk of strange problems which are related.
--jason
On Feb 3, 2007, at 2:32 PM, Jorg Heymans wrote:
Jason Dillon wrote:
When I was building locally and on r
On Wed, February 7, 2007 3:46 am, Franz Allan Valencia See wrote:
> I don't know why this should not work ( and I don't have a Mac to try
> it on). Try entering the os name all in small caps ( i.e. "mac os x"
> ).
Small case works, even though when you print the value of ${os.name} the
operating
Sounds like the well-known Cobertura 2.1 problem. Try explicitly specifying
version 2.0 of the plugin and see if that fixes it.
- Original Message -
From: "drekka" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, February 07, 2007 1:13 AM
Subject: Lifecycle issues with Cobertura plugin and c
25 matches
Mail list logo
