Hi,
Our build has a dependency on javax.xml.ws:jaxws-api:2.1. And we have the
java.net configured as a maven repo in our pom.xml. The build fails randomly
because the same artifact is available at [2] but it has a different pom as
[1]. A bunch of transitive dependencies are missing in [2], suc
Big +1 from me too.
- Joakim
Wendy Smoak wrote:
There was some discussion on IRC last night about branching Archiva
1.0 to allow trunk to move on as 1.1.
Thoughts?
It would seem to be best in Surefire to me - the assertion in Maven
should really be covered by a unit test?
On 26/01/2008, at 5:25 AM, Dan Fabulich wrote:
Class path ordering is tricky, and changed recently. Benjamin
Bentmann provides a regression test in SUREFIRE-428.
However, I'm not
great, but
- who is going to enforce it?
- who is going to say what the right pom is for a project that doesnt
build with Maven?
there's still people saying that poms should be modifiable!
and the fact that maven is ready for business doesnt mean taht you can
use anything however you want, you sh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
I am sometimes late on threads but anyways...
| i don't agree, the point of not having a pom there is to be able to
| add one later with the right info. If you work against something
| without pom, hey, it's your decision, but you are awar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
typically if maven fails with something like "required artifact is missing"
you can have a look at the module where the error occurred and scan
the dependencies.
As additional support maven typically prompts an error report including
someth
+1, to be able to freely imagine what we could implement in 1.1.
In 1.0 branch we'll just do some fixes or improvements.
Arnaud
On Jan 25, 2008 4:54 PM, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> There was some discussion on IRC last night about branching Archiva
> 1.0 to allow trunk to move on as
Class path ordering is tricky, and changed recently. Benjamin Bentmann
provides a regression test in SUREFIRE-428.
However, I'm not certain if I should apply it in Surefire, because we use
those integration tests to verify backwards compatibility with older
versions of Maven.
My initial t
Never mind. I found it under /maven/enforcer.
-Original Message-
From: Jason Chaffee [mailto:[EMAIL PROTECTED]
Sent: Friday, January 25, 2008 11:44 AM
To: Maven Developers List
Cc: Maven Users List
Subject: where is the source for maven-enforcer-plugin in SVN?
It doesn't seem to live in
It doesn't seem to live in maven/plugins/trunk and the latest build
1.0-alpha-3 doesn't have the all of the functionality documented on the
site. In particular, it does not support which
I would like to use.
I'm not able to access the zone...
-Original Message-
From: Raphaël Piéroni [mailto:[EMAIL PROTECTED]
Sent: Friday, January 25, 2008 1:41 PM
To: Maven Developers List
Subject: archetype fails on continuum
Hi
I noticed that the current definition of continuum projects
for archetype (http
Benjamin Bentmann wrote:
I see. Now, if the user can provide an option to Surefire, indicating
that the unit tests do not have inter-class dependencies, wouldn't this
allow to get back the old behavior? I.e. enabling Surefire to pass test
classes individually into TestNG?
That option sounds
Hi
I noticed that the current definition of continuum projects
for archetype (http://maven.zones.apache.org/continuum/)
use the trunk scm but i moved them to the branch du to
the result of the vote i called.
Could any one with karma modify the configuration for continuum
to build the old archetyp
dfabulich wrote:
>
> Typically it's used for slow tests; you can identify a subset of tests
> that you want to run and just run those. (You can even pull just one
> method from Class X, and another method from Class Y, and so on.)
>
Thanks for the explanation. To me, this seems more useful f
I'll take care of it, thanks for pointing it out.
-Original Message-
From: Mark Hobson [mailto:[EMAIL PROTECTED]
Sent: Friday, January 25, 2008 10:03 AM
To: dev@maven.apache.org
Subject: Re: svn commit: r615232 - in
/maven/plugins/trunk/maven-dependency-plugin/src:
main/java/org/apache/m
Steve Loughran wrote:
What I propose is that, in order to avoid destroying information, Surefire
should generate XML that looks like Example 7 (all-in-one-file), and not
try to fake it to look like Example 2 (one-file-per-class). (TestNG's
junit-like output also generates files like Example 7.)
Benjamin Bentmann wrote:
For my curiosity: What would be the benefit of setting up a hand-crafted
test suite? I am a lazy guy and prefer the dumb machine to do the nasty
things for me so I really like the idea of just dropping a test class into
src/test/java without bothering to additionally mai
Brian, not sure if this was a midway commit but there's a bunch of
other @since tags that need updating - search for "2.0-alpha-5" and
"2.0-alpha-6". I don't mind updating them but don't want to confuse
matters if you're about to release.
Cheers,
Mark
On 25/01/2008, [EMAIL PROTECTED] <[EMAIL PR
Vote has passed:
Binding: +6 (Brian, Vincent, Lukas, Stephane, Arnaud, Jason)
NonBinding: +5 (Mark, Rahul, Olivier, Mauro, Marat)
Huge voter turnout for this one ;-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional c
Yes, it can be done like that.
Emmanuel
On Jan 25, 2008 1:16 PM, Benoit Decherf <[EMAIL PROTECTED]> wrote:
> Ok, so for the release process, the user should be able to select the
> profile he want to use.
> There should be a combo with the list of available profiles in the
> releasePrepare.jsp ?
20 matches
Mail list logo
