Issue Subscription
Filter: Design & Best Practices (24 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
On 2010-12-16 00:17, Brett Porter wrote:
>
> On 16/12/2010, at 10:00 AM, Dennis Lundberg wrote:
>
>> On 2010-12-15 23:03, Jesse Farinacci wrote:
>>> Greetings,
>>>
>>> On Wed, Dec 15, 2010 at 4:52 PM, Dennis Lundberg wrote:
https://cwiki.apache.org/confluence/display/MAVEN/Proposal+--+
+1
-Lukas
Kristian Rosenvold wrote:
Highlights of the release:
* Pluggable providers are now supported, as well as manual provider
selection
* 2.7 is significantly smaller and lighter than earlier 2.x versions
(Only 30% of the download size)
* A large chunk of the highest voted issues have be
+1 (non-binding)
This one works great too!
On Thu, Dec 16, 2010 at 5:38 AM, chemit wrote:
> On Thu, 16 Dec 2010 11:46:40 +0100
> Kristian Rosenvold wrote:
>
> +1 (non binding)
>
>
>
> --
> Tony Chemit
>
> tél: +33 (0) 2 40 50 29 28
> email: che...@codelutin.com
> http://ww
Hi Baptiste,
Baptiste MATHUS wrote:
> 2010/12/16 Jörg Schaible
>
>> Hi Baptiste,
>>
>> Baptiste MATHUS wrote:
>>
>> > But then how do you handle releases of the referencing projects? A
>> > clean release must never reference any snapshot, I don't see how you do
>> > it.
>>
>> Hmm, Jörg Hohwille
+1 for the retirement language
I'm confused about the creation language too, but I'm guessing that's
just a sidetrack. For retirement this seems okay, but I'd also urge the
injection of a relocation POM instead of a final release...for the
reasons already covered (related to releasing from a S
2010/12/16 Jörg Schaible
> Hi Baptiste,
>
> Baptiste MATHUS wrote:
>
> > But then how do you handle releases of the referencing projects? A clean
> > release must never reference any snapshot, I don't see how you do it.
>
> Hmm, Jörg Hohwiller pointed out that *he* does not release those artifact
On Thu, 16 Dec 2010 11:46:40 +0100
Kristian Rosenvold wrote:
+1 (non binding)
--
Tony Chemit
tél: +33 (0) 2 40 50 29 28
email: che...@codelutin.com
http://www.codelutin.com
-
To unsubscribe, e-mail: dev-
Yes; multiple are permitted. And they can generate a common test-run report.
Kristian
Den 16.12.2010 11:58, skrev Mark Derricutt:
Cool, I'll take a look.
Does this mean we can have -multiple- providers at once? i.e.
previously if you had TestNG on the class path you couldn't also have
JUnit4
+0.9
The proposal starts off talking about creation and retirement and then
speaks exclusively about retirement on step 2 and then step 3 is back
to both.
I'd like to see a clearer outline for creation
-Stephen
On 15 December 2010 21:52, Dennis Lundberg wrote:
> Hi
>
> No one objected to the p
Cool, I'll take a look.
Does this mean we can have -multiple- providers at once? i.e.
previously if you had TestNG on the class path you couldn't also have
JUnit4 tests.
( I'm thinking of writing a clojure-test provider to go along with the
clojure-maven-plugin ).
--
"Great artists are extreme
From the staged 2.7 docs:
http://maven.apache.org/plugins/maven-surefire-plugin-2.7/api.html
http://maven.apache.org/plugins/maven-surefire-plugin-2.7/examples/providers.html
The proposed api's can be seen in:
http://maven.apache.org/surefire/staging/surefire-api/apidocs/index.html
As can be se
Highlights of the release:
* Pluggable providers are now supported, as well as manual provider
selection
* 2.7 is significantly smaller and lighter than earlier 2.x versions
(Only 30% of the download size)
* A large chunk of the highest voted issues have been fixed.
* Some performance optimization
+0 (non-binding)
One comment I would make is if the plugin moves to another forge (hence
different groupId) a relocation pom should be created at the "old" location -
not just an update to the SCM.
/James
-Original Message-
From: Dennis Lundberg [mailto:denn...@apache.org]
Sent: 15 Dec
Kristian,
Where can I read about writing a pluggable provider? If it's what I
assume then gimme gimme gimme! :-)
Mark
--
"Great artists are extremely selfish and arrogant things" — Steven
Wilson, Porcupine Tree
On Wed, Dec 15, 2010 at 12:21 PM, Kristian Rosenvold
wrote:
> * Pluggable provid
Hi Baptiste,
Baptiste MATHUS wrote:
> But then how do you handle releases of the referencing projects? A clean
> release must never reference any snapshot, I don't see how you do it.
Hmm, Jörg Hohwiller pointed out that *he* does not release those artifacts.
So is this a question to my reply in
+1
Agree too on apache-extras.org as a nice place.
2010/12/15 Dennis Lundberg :
> Hi
>
> No one objected to the proposal I made on November 1. Jason and I have
> polished the proposal based on the comments that were made. The final
> (?) version can be found here:
>
> https://cwiki.apache.org/con
+1
Emmanuel
On Wed, Dec 15, 2010 at 8:25 PM, Dennis Lundberg wrote:
> Hi
>
> I have some features I'd like to work on for the Changes Plugin. To
> simplify the work I would like to start using Java 5 features, such as
> generics for collections.
>
> The last release was version 2.3 and after th
I cancel this vote. Will be respinning shortly for SUREFIRE-665 and a
jdk1.3 (!) fix.
Kristian
Den 16.12.2010 08:44, skrev Lukas Theussl:
+1
-Lukas
Kristian Rosenvold wrote:
Highlights of the release:
* Pluggable providers are now supported, as well as manual provider
selection
* 2.7 is s
But then how do you handle releases of the referencing projects? A clean
release must never reference any snapshot, I don't see how you do it.
Le 16 déc. 2010 00:33, "Jörg Hohwiller" a écrit :
> Hi there,
>
> FYI:
>
> I use "SNAPSHOT" as version for internal artifacts (site-configurations
with
> c
20 matches
Mail list logo
