agreed, though I hope it is short lived :)
On 25/01/2008, at 11:54 PM, 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?
--
Wendy
There was some discussion on IRC last night about branching Archiva
1.0 to allow trunk to move on as 1.1.
Thoughts?
--
Wendy
Hi
I m' working on http://jira.codehaus.org/browse/CONTINUUM-1633 because
it's blocker for us.
I think that some other bugs on continuum release should be corrected if
the release process is externalized to mvn.
But there is a problem with CONTINUUM-1572
A profile can't be applied to a project because generally, users want to
build their projects for different environment.
Maybe, we'll add a defaut project profile in future versions that can be
overriden in the build definition
Emmanuel
On Jan 25, 2008 11:31 AM, Benoit Decherf [EMAIL PROTECTED]
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 ?
Benoit.
Emmanuel Venisse wrote:
A profile can't be applied to a project because generally, users want to
build
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
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 requiresPluginVersions which
I would like to use.
-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
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],
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?
-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
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
+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
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
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
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:
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
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
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 ?
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
22 matches
Mail list logo
