+1
Fabrice.
On 3/16/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi,
Patrick has, for at least a couple months, been working on MNG-1577,
has written extensive tests, changed and altered patches for anything
and everything that's been asked of him. He worked with Mike and
Ralph discussing the
You've lost me, sorry. What type of page are you trying to create?
I can see how this makes it possible to make lightweight reports. I
don't see how it's useful in most documentation. I would think the
former would naturally be in a separate section somewhere, as opposed
to having to specif
I meant to say:
It currently skips snapshots but any released artifacts that
don't match will potentially cause a problem with a build with MNG-1577
applied.
I'm hoping that we can get this fixed up, release the analyze test and
make MNG-1577 the default behavior. We can not only describe it clear
I whipped up a mojo to test a build for cases where the resolved
dependency is different than what is set in the dependencyManagement
section. Use maven-dependency-plugin 2.0-alpha-3-SNAPSHOT (deployed to
snapshot repo) run as "mvn dependency:analyze" and it will display
mismatches. It currently sk
On 17 Mar 07, at 12:31 AM 17 Mar 07, Ralph Goers wrote:
Jason van Zyl wrote:
I will work with Patrick to put the old and new in 2.0.x. If it
really comes down to turning it off by default, which would be an
immense shame, then so be it and people will just have to turn it
on. We'll just
Jason van Zyl wrote:
I will work with Patrick to put the old and new in 2.0.x. If it really
comes down to turning it off by default, which would be an immense
shame, then so be it and people will just have to turn it on. We'll
just devise a very easy way to turn it on like a property in the
Hi,
I would like to strip down doxia to few modules and move the site and
decoration specific modules out of doxia itself. For doxia itself I
would like to reduce it to:
doxia-sink-api
doxia-core
doxia-modules
The site stuff doesn't belong in Doxia proper it and would make more
sense in
On 16 Mar 07, at 8:00 PM 16 Mar 07, Wendy Smoak wrote:
On 3/16/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
I'm leaning toward being on by default and letting people fully
utilize Velocity anywhere they like.
If Velocity is involved, please make sure the EscapeTool is available
so you can c
Hrm... I though I replied to this mail hours ago... but looks like I
didn't...
Ok, we've got different approaches here. I'll line them out to
summarize:
I appreciate you taking the time :-)
Mine:
- use an integration testing plugin like maven-it-plugin to run
test projects
placed in s
On 3/16/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
I'm leaning toward being on by default and letting people fully
utilize Velocity anywhere they like.
If Velocity is involved, please make sure the EscapeTool is available
so you can convince it *not* to process certain expressions. This is
Mike,
Good plan. This is exactly what I was getting at - but I thought we
could already do this from the branch that the feature was
implemented on? That's what I was intending to use.
I'm obviously having trouble grokking the actual implications of this
- I was getting the clear impressi
I'll be going there.
It'd be great if we could all get together.
--
Dennis Lundberg
Brett Porter wrote:
Hi,
Who here will be at ApacheCon in May? I know Jason is as he is speaking.
Anyone want to get together there?
I'm currently working on the content of the training I'm doing... if
anyon
On 16 Mar 07, at 6:15 PM 16 Mar 07, Brett Porter wrote:
I think I'd like the option to, but not every time. Maybe it
belongs closer to the reporting infrastructure (the download pages
are more like the SCM/mail list types of pages).
Maybe that's the real future of those types of pages - th
On 16 Mar 07, at 6:09 PM 16 Mar 07, Emmanuel Venisse wrote:
Jason van Zyl a écrit :
Hi,
Do you think people would like to use Velocity for the pages of
documentation regardless of format. I've hooked it in to try it
but there are a couple options.
1) Use Velocity to process the pages bef
I think I'd like the option to, but not every time. Maybe it belongs
closer to the reporting infrastructure (the download pages are more
like the SCM/mail list types of pages).
Maybe that's the real future of those types of pages - the ability to
write simple velocity pages that get process
Jason van Zyl a écrit :
Hi,
Do you think people would like to use Velocity for the pages of
documentation regardless of format. I've hooked it in to try it but
there are a couple options.
1) Use Velocity to process the pages before going to the respective
doxia parser
2) Make 1) optional
+1
On 17/03/2007, at 1:44 AM, Jason van Zyl wrote:
Hi,
Patrick has, for at least a couple months, been working on
MNG-1577, has written extensive tests, changed and altered patches
for anything and everything that's been asked of him. He worked
with Mike and Ralph discussing the problem,
+1
Arnaud
On 16/03/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
+1
- Joakim
Jason van Zyl wrote:
> Hi,
>
> Patrick has, for at least a couple months, been working on MNG-1577,
> has written extensive tests, changed and altered patches for anything
> and everything that's been asked of him.
Hi,
Do you think people would like to use Velocity for the pages of
documentation regardless of format. I've hooked it in to try it but
there are a couple options.
1) Use Velocity to process the pages before going to the respective
doxia parser
2) Make 1) optional
3) Just interpolate the
+1
Arnaud
On 16/03/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
+1. No regression.
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Friday, March 16, 2007 1:12 PM
To: Maven Developers List
Subject: [VOTE] (take 2) Release Maven PMD Plugin 2.2
Ok, Take 2. The reg
Fabrizio Giustina wrote:
A big +1 for making it a default
I am also +1 on adding this to 2.0.6: for me this would just mean
removing tons of unneeded/workaround dependency from tons of poms. I
agree that, although consistent for some time, this behavior
introduces so much problems that should
On 16 Mar 07, at 4:02 PM 16 Mar 07, Carlos Sanchez wrote:
On 3/16/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>i don't follow you here, the problem is when 2.0.5 builds get some
version
>"by default" (they don't override it). Those builds would get
another
version in 2.0.6
I think it sim
A big +1 for making it a default
I am also +1 on adding this to 2.0.6: for me this would just mean
removing tons of unneeded/workaround dependency from tons of poms. I
agree that, although consistent for some time, this behavior
introduces so much problems that should be considered a bug and not
That sounds like a great idea, Mike. It's all academic until we put
something out there.
-j
On 3/16/07, Mike Perham <[EMAIL PROTECTED]> wrote:
The key question to me is: are existing 2.0.5 builds going to be
better or worse after this upgrade? I would prefer to see less
speculation and more b
The key question to me is: are existing 2.0.5 builds going to be
better or worse after this upgrade? I would prefer to see less
speculation and more bits. Put out a Maven 2.0.6 snapshot that people
can try with their project and get reports from the people in this
thread. If no one has problems
sorry guys, wrong email. This was addressed to piotr.
Stéphane
On 3/16/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote:
More issues that can be fixed (I can provide assistance):
http://jira.codehaus.org/browse/MWAR-91
http://jira.codehaus.org/browse/MWAR-72
I'd like your opinion for the followi
More issues that can be fixed (I can provide assistance):
http://jira.codehaus.org/browse/MWAR-91
http://jira.codehaus.org/browse/MWAR-72
I'd like your opinion for the following:
http://jira.codehaus.org/browse/MWAR-76
http://jira.codehaus.org/browse/MWAR-70
On 3/13/07, Piotr Tabor <[EMAIL PRO
+1
Dan
On Saturday 10 March 2007 18:25, 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
+1
- Joakim
Jason van Zyl wrote:
> Hi,
>
> Patrick has, for at least a couple months, been working on MNG-1577,
> has written extensive tests, changed and altered patches for anything
> and everything that's been asked of him. He worked with Mike and Ralph
> discussing the problem, getting the p
+1
- Joakim
Daniel Kulp wrote:
> Following the "release often" mantra... :-(
>
>
> Several projects have hit "Critical" bugs that is causing builds to fail
> when using the remote-resources plugin.1.0-alpha-4 contains no new
> functionality. It just fixes the two critical bugs.
>
>
>
Here are the results of this vote:
+1 (3): Dennis Lundberg, Brett Porter, Emmanuel Venisse.
I will proceed with the release.
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 be
On 3/16/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>i don't follow you here, the problem is when 2.0.5 builds get some
version
>"by default" (they don't override it). Those builds would get another
version in 2.0.6
I think it simply boils down to what Patrick wrote:
"For existing projects i
On 3/16/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
On 3/16/07, John Casey <[EMAIL PROTECTED]> wrote:
> If the solution to this situation has been to define the dependency
locally
> with the version you want, how can having a dependencyManagement section
> that works transitively possibly be r
Carlos Sanchez wrote:
On 3/16/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
Carlos Sanchez wrote:
> now poms in the repo that have dependencyManagement sections will
> start to change the behavior of current builds and people with 2.0.5
> will get very different results than people with 2
First, it's not clear to me that depMgmt is used from a POM that is loaded
out of the repository...I'll take another look, though. In any case,
whatever B does to specify its own dependencies, you'll have to override in
one form or another in A, correct? If B specifies a dependency on D ==
2.0dire
>i don't follow you here, the problem is when 2.0.5 builds get some
version
>"by default" (they don't override it). Those builds would get another
version in 2.0.6
I think it simply boils down to what Patrick wrote:
"For existing projects in which the workaround was not used, then I
would que
On 3/16/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
You're only describing the case where you override the version by specifying
a transitive dep directly. If you don't, then it's unpredictable.
If I say in my pom 'i want junit 4 for my modules' and some transitive dep has
junit 3
my build c
Dan,
I have tried the latest version of maven-checkstyle-plugin built from
SVN and now it is working. Thanks, nice job!
Daniel Kulp wrote:
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 Mar
On 3/16/07, John Casey <[EMAIL PROTECTED]> wrote:
First, it's not clear to me that depMgmt is used from a POM that is loaded
out of the repository...I'll take another look, though. In any case,
whatever B does to specify its own dependencies, you'll have to override in
one form or another in A, c
On 3/16/07, John Casey <[EMAIL PROTECTED]> wrote:
If the solution to this situation has been to define the dependency locally
with the version you want, how can having a dependencyManagement section
that works transitively possibly be relevant to those builds? Carlos, how
can this possibly break
Well, you voted the first time around, but that vote failed. So a new
vote had to be called for.
Stephane Nicoll wrote:
I did vote already for this one right? (I don't remember actually and
I can't find that back in my mails).
In any case +1
Stéphane
On 3/15/07, Dennis Lundberg <[EMAIL PROTE
Here are the results of this vote:
+1 (3 + 1 non-binding): Dennis Lundberg, Brett Porter, Stephane Nicoll
and Jerome Lacoste (non-binding).
I will proceed with the release.
Dennis Lundberg wrote:
Hi,
Trying this vote once more. This time with staging.
This release is a preparation for a ne
On 3/16/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
Carlos Sanchez wrote:
> now poms in the repo that have dependencyManagement sections will
> start to change the behavior of current builds and people with 2.0.5
> will get very different results than people with 2.0.6 which i don't
> thin
On Mar 16, 2007, at 3:58 AM, Kenney Westerhof wrote:
Ok, we've got different approaches here. I'll line them out to
summarize:
Mine:
- use an integration testing plugin like maven-it-plugin to run
test projects
placed in src/it/*/pom.xml against the current artifact, which is
not installe
That would probably be helpful thanks, that will certainly get it
recorded.
Andy
On 16 Mar 2007, at 18:14, Brian E. Fox wrote:
Should we file a 2.0.6 defect for this and link it to PLX-287?
Technically something needs to happen in Maven for this to get
fixed (ie
update the pom)
-Orig
If the solution to this situation has been to define the dependency locally
with the version you want, how can having a dependencyManagement section
that works transitively possibly be relevant to those builds? Carlos, how
can this possibly break those builds?
I think this issue is way too import
On 16 Mar 07, at 2:49 PM 16 Mar 07, Brian E. Fox wrote:
If my choice was 2.0.6 without this or call it 2.1 with it, then I say
call it 2.1. This move should imply an end to 2.0 releases though
because the last thing we need is 3 active releases.
I will work with Patrick to put the old and ne
Carlos Sanchez wrote:
it's not unpredictable at all, it is pretty clear that to force a
version in a project you need to add it in your pom and
dependencyManagement doesn't affect transitive dependencies, it's in
the documentation,
Where?
and even in the jira issue Brett says that it was
do
On 16 Mar 07, at 2:46 PM 16 Mar 07, Carlos Sanchez wrote:
it's not unpredictable at all, it is pretty clear that to force a
version in a project you need to add it in your pom and
dependencyManagement doesn't affect transitive dependencies, it's in
the documentation, and even in the jira issue
If my choice was 2.0.6 without this or call it 2.1 with it, then I say
call it 2.1. This move should imply an end to 2.0 releases though
because the last thing we need is 3 active releases.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Se
it's not unpredictable at all, it is pretty clear that to force a
version in a project you need to add it in your pom and
dependencyManagement doesn't affect transitive dependencies, it's in
the documentation, and even in the jira issue Brett says that it was
done on purpose.
http://maven.apache.
How hard would it be to make a tool to detect the condition where this
would cause a problem? Wouldn't you just compare the resolved artifacts
with the dependencyManagement section and see where there are
differences? Something like a pre-upgrade validator.
-Original Message-
From: Daniel
I agree. Anything that makes a "unpredictable behavior" predictable is
a bug fix that should go in a patch. We've had to do all kinds of
wacky things to work around unpredictable behavior. (we gotten
different behavior depend on the JDK we use, that's bad) 2.0.5 helped in
some cases, but
+1 for patching 2.0.6
I have yet to hear a single convincing argument for maintaining broken
behavior. Who cares if people depend on it being broken? Don't upgrade. It's
a defect, not a feature change. Pushing this to a major version is way
overkill.
On 3/16/07, Carlos Sanchez <[EMAIL PROTECTED]
On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:
I agree with Brett, this is a 2.1 change, not a 2.0.x
Do you fully understand what the current behavior is and what this
patch fixes? You are essentially condemning users to complete
unpredictability. I really think that a build s
+1. No regression.
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Friday, March 16, 2007 1:12 PM
To: Maven Developers List
Subject: [VOTE] (take 2) Release Maven PMD Plugin 2.2
Ok, Take 2. The regression in the URL handling is fixed (and unit test
added).
I'
Should we file a 2.0.6 defect for this and link it to PLX-287?
Technically something needs to happen in Maven for this to get fixed (ie
update the pom)
-Original Message-
From: Andrew Williams [mailto:[EMAIL PROTECTED]
Sent: Friday, March 16, 2007 1:06 PM
To: Maven Developers List
Subject
+1
On 16 Mar 2007, at 17:16, Daniel Kulp wrote:
Following the "release often" mantra... :-(
Several projects have hit "Critical" bugs that is causing builds to
fail
when using the remote-resources plugin.1.0-alpha-4 contains no new
functionality. It just fixes the two critical b
+1
On 16 Mar 07, at 1:16 PM 16 Mar 07, Daniel Kulp wrote:
Following the "release often" mantra... :-(
Several projects have hit "Critical" bugs that is causing builds to
fail
when using the remote-resources plugin.1.0-alpha-4 contains no new
functionality. It just fixes the two
I agree with Brett, this is a 2.1 change, not a 2.0.x
Now as Jochen says, nothing prevents pushing stuff from 2.1 to 2.2 and
get an earlier 2.1, i though we were going to do it anyway.
On 3/16/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
On 3/16/07, Brett Porter <[EMAIL PROTECTED]> wrote:
>
Ack, forgot the details:
Staging area:
http://people.apache.org/~dkulp/stage_remoteresources/
Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.0-alpha-4/
Dan
On Friday 16 March 2007 13:16, Daniel Kulp wrote:
> Following the "release often" mantra...
Following the "release often" mantra... :-(
Several projects have hit "Critical" bugs that is causing builds to fail
when using the remote-resources plugin.1.0-alpha-4 contains no new
functionality. It just fixes the two critical bugs.
Release Notes - Maven 2.x Remote Resources Plu
Ok, Take 2. The regression in the URL handling is fixed (and unit test
added).
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/~d
This is now fixed in the latest plexus, which is being used in 2.1-
SNAPSHOT.
We are currently trying to figure if it is feasible to update the
2.0.x branch at this time.
Andy
On 16 Feb 2007, at 16:30, Brian E. Fox wrote:
Since this is a plexus issue, I might be grasping, but we are still
s
+1, definitely.
-john
On 3/16/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi,
Patrick has, for at least a couple months, been working on MNG-1577,
has written extensive tests, changed and altered patches for anything
and everything that's been asked of him. He worked with Mike and
Ralph disc
Hi everyone,
I've performed a fairly significant refactoring of the lifecycle executor on
the 2.1-lifecycle-refactor branch. The changes allow Maven to construct a
build plan before execution begins in earnest, which contains all of the
mojos and their configurations and is then rendered to a Lis
Are non-binding votes allowed for priv votes?
If so +1
Andy
On 16 Mar 2007, at 14:44, Jason van Zyl wrote:
Hi,
Patrick has, for at least a couple months, been working on
MNG-1577, has written extensive tests, changed and altered patches
for anything and everything that's been asked of him
+1, I agree with Kenney that folk will be able to remove a lot of
workaround snippets from their poms,
the sooner the better.
Andy
On 16 Mar 2007, at 11:48, Kenney Westerhof wrote:
I think it won't break builds at all.
I think that people have lots of workarounds in their poms right now
to
+1
Dan
On Friday 16 March 2007 10:44, Jason van Zyl wrote:
> Hi,
>
> Patrick has, for at least a couple months, been working on MNG-1577,
> has written extensive tests, changed and altered patches for anything
> and everything that's been asked of him. He worked with Mike and
> Ralph discussing
Yes, I know this I just did not explain well :-p
On 16 Mar 2007, at 07:30, Emmanuel Venisse wrote:
ok, we need it :( it is called by a component in maven deps.
Emmanuel
Emmanuel Venisse a écrit :
I don't misunderstand.
I just say that the component declared in maven dep is with
'maven' rol
+1
-Vincent
On Mar 16, 2007, at 3:44 PM, Jason van Zyl wrote:
Hi,
Patrick has, for at least a couple months, been working on
MNG-1577, has written extensive tests, changed and altered patches
for anything and everything that's been asked of him. He worked
with Mike and Ralph discussing
Vincent,
Two issues:
1) I notice trunk of clover uses the ResourceManager. Thus, it
probably suffers from the same problem as PMD and Checkstyle. Thus,
the license location is probably not able to be a URL like the docs say
and would thus be a regression from 2.3.
2) You didn't provid
+1
On 3/16/07, Vincent Massol <[EMAIL PROTECTED]> wrote:
Hi,
As Mike Perham pointed out the Clover license for the release clover
plugin (ie v2.3) has expired. Thus the urgency to release version 2.4.
Here's the release notes for 2.4:
** Bug
* [MCLOVER-45] - Excluded files should be adde
>I'm all for testing this more thoroughly for anything that might not be
> spot on with the resolution but the process is that any transitive
>dependency is aligned to the depMan section unless a dependency in a
>child project overrides the version. I believe users would expect this
>to be the b
+1
Emmanuel
Vincent Massol a écrit :
Hi,
As Mike Perham pointed out the Clover license for the release clover
plugin (ie v2.3) has expired. Thus the urgency to release version 2.4.
Here's the release notes for 2.4:
** Bug
* [MCLOVER-45] - Excluded files should be added to compiled sour
+1
Stéphane
On 3/16/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi,
Patrick has, for at least a couple months, been working on MNG-1577,
has written extensive tests, changed and altered patches for anything
and everything that's been asked of him. He worked with Mike and
Ralph discussing the
+1
Jason.
On 16 Mar 07, at 10:45 AM 16 Mar 07, Vincent Massol wrote:
Hi,
As Mike Perham pointed out the Clover license for the release
clover plugin (ie v2.3) has expired. Thus the urgency to release
version 2.4.
Here's the release notes for 2.4:
** Bug
* [MCLOVER-45] - Excluded fi
On 16 Mar 07, at 10:39 AM 16 Mar 07, Brian E. Fox wrote:
I agree (already voted) but which is easier to defend? A user who gets
upset that giving them more control broke their build
I'm all for testing this more thoroughly for anything that might not
be spot on with the resolution but the p
+1 (of course!)
On 3/16/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi,
Patrick has, for at least a couple months, been working on MNG-1577,
has written extensive tests, changed and altered patches for anything
and everything that's been asked of him. He worked with Mike and
Ralph discussing t
+1
Emmanuel
Jason van Zyl a écrit :
Hi,
Patrick has, for at least a couple months, been working on MNG-1577, has
written extensive tests, changed and altered patches for anything and
everything that's been asked of him. He worked with Mike and Ralph
discussing the problem, getting the patc
+1
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Friday, March 16, 2007 10:45 AM
To: Maven Developers List
Subject: [VOTE] Commit Privs for Patrick Schneider
Hi,
Patrick has, for at least a couple months, been working on MNG-1577, has
written extensive tests,
Hi,
As Mike Perham pointed out the Clover license for the release clover
plugin (ie v2.3) has expired. Thus the urgency to release version 2.4.
Here's the release notes for 2.4:
** Bug
* [MCLOVER-45] - Excluded files should be added to compiled sources
* [MCLOVER-53] - Clover plugin
Hi,
Patrick has, for at least a couple months, been working on MNG-1577,
has written extensive tests, changed and altered patches for anything
and everything that's been asked of him. He worked with Mike and
Ralph discussing the problem, getting the patches prepared and in
for this fix,
I agree (already voted) but which is easier to defend? A user who gets
upset that giving them more control broke their build (but is easy to
fix) or constantly telling people who assume the new functionality that
the need to turn it on? Won't they be even more annoyed that it wasn't
until they debu
On 3/16/07, Brett Porter <[EMAIL PROTECTED]> wrote:
Our users must be able to trust point releases are safe upgrades.
Let's start moving on putting out 2.1 milestone releases instead.
Agreed. On the other hand, most others seem to consider this change important.
So, why not simply renaming 2.
On 16 Mar 07, at 2:55 AM 16 Mar 07, Brett Porter wrote:
-1, at this point. I'd like to look at some specific test cases to
see how badly it might break a build - so I could be convinced.
No matter how bad the existing behaviour, it is consistent once in
place.
It's not consistent at all.
I'm +1.
I don't think that making dependencies in Maven more predictable or
deterministic can wait for 2.1, especially considering that it has a fairly
lengthy road before it gets to 2.1-final. Currently, what we have in place
seems buggy, whatever the reality, so I don't see it as worth defendin
+1 (non-binding)
Our integration tests are way too simplistic to test this so we definitely
need to test this against 'real life' complex builds.
FWIW, we have been using this patch on our 60+ module build for two months
or so, with extensive use of demMgmt/transitive dependencies exercising t
Brett,
As others have pointed out, most people have gotten around this by
explicitly specifying the dependencies in their pom, even though they
aren't direct dependencies. This change won't affect them. It only
affects folks who let Maven handle transitive dependencies and it will
also only
Jason van Zyl wrote on Friday, March 16, 2007 1:33 AM:
> 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 b
I think it won't break builds at all.
I think that people have lots of workarounds in their poms right now
to overcome this problem - specifying transitive dependencies directly,
which they don't directly use, but just to enforce that version being used. I've
done so myself quite a few times. Tho
Ok, we've got different approaches here. I'll line them out to summarize:
Mine:
- use an integration testing plugin like maven-it-plugin to run test projects
placed in src/it/*/pom.xml against the current artifact, which is not installed
in any repository yet.
- The embedder is fed the current
[Sorry for cross posting, but this was intended to the developper list.]
On 3/15/07, Jerome Lacoste <[EMAIL PROTECTED]> wrote:
Hi,
further care must be taken when writing plugins considering that maven can
be embedded. Maven sort of acts as a container for code. And maven itself
can be embedde
I did vote already for this one right? (I don't remember actually and
I can't find that back in my mails).
In any case +1
Stéphane
On 3/15/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
I need one more vote...
--
Dennis Lundberg
Dennis Lundberg wrote:
> Hi,
>
> Trying this vote once more. T
-1, at this point. I'd like to look at some specific test cases to
see how badly it might break a build - so I could be convinced.
No matter how bad the existing behaviour, it is consistent once in
place. I think it's unacceptable to drop this into a .0.x release, no
matter what the release
95 matches
Mail list logo
