Kenney Westerhof wrote:
[snip]
>>> The meaning of depMgt is different, applied to either local deps or
>>> transitive deps, and it's not consistent.
>>>
>>> This somewhat describes the situation:
>>> - depMgt for artifact X is used to provide defaults for direct
>>> dependencies of artifact X,
>>
Ralph Goers wrote:
Kenney Westerhof wrote:
This somewhat describes the situation:
- depMgt for artifact X is used to provide defaults for direct
dependencies of artifact X,
and for overrides of transitive dependencies on X,
unless there's also a direct dependency on X in which case the di
Jörg Schaible wrote:
Kenney Westerhof wrote:
Hi,
Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is
what I found:
P with dependencyManagement for lucene 1.3
|
+ my-dep with dependency on lucene 1.4.3
+ my-app with dependency on my-dep
(I modified the attached projec
we need a new element, like 'transitiveDependencyManagement'.
This is something I hope we won't support in 2.1...
-- Kenney
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 16, 2007 7:06 AM
To: Maven Developers List
Subject: depM
Kenney Westerhof wrote:
This somewhat describes the situation:
- depMgt for artifact X is used to provide defaults for direct
dependencies of artifact X,
and for overrides of transitive dependencies on X,
unless there's also a direct dependency on X in which case the direct
dependency is us
Kenney Westerhof wrote:
> Hi,
>
> Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is
> what I found:
>
> P with dependencyManagement for lucene 1.3
> |
> + my-dep with dependency on lucene 1.4.3
> + my-app with dependency on my-dep
>
> (I modified the attached project lo
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 16, 2007 7:06 AM
To: Maven Developers List
Subject: depMgt (mng-1577 again)
Hi,
Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is what
I found:
P with dependencyManagement for lucene 1.3
|
+ my-dep
Hi,
Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is what
I found:
P with dependencyManagement for lucene 1.3
|
+ my-dep with dependency on lucene 1.4.3
+ my-app with dependency on my-dep
(I modified the attached project locally; rename my-app to my-dep and add
my-ap
didn't write the spec first and anything that has been
done has been embodied in code and subject to changes like MNG-1577.
We need a spec, define the behavior and then write to that. Trying to
do anything with 2.0.x or the artifact resolution mechanism as it
stands is a complete waste of time. D
t; wrote:
Ultimately the short answer is who cares what 2.0.x does.
Why?
Because we didn't write the spec first and anything that has been
done has been embodied in code and subject to changes like MNG-1577.
We need a spec, define the behavior and then write to that. Trying to
do anything wi
does.
Why?
Because we didn't write the spec first and anything that has been
done has been embodied in code and subject to changes like MNG-1577.
We need a spec, define the behavior and then write to that. Trying to
do anything with 2.0.x or the artifact resolution mechanism as it
stands i
; On 6/6/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
> > >
> > > Sorry for the 1950's Horror Movie Catchphrase. I'm just odd
like that.
> ;-)
> > >
> > > The following has been filed as
> http://jira.codehaus.org/browse/MNG-3038
> > >
> > of D it gets, because it has no direct dependency on D.
> >
> >
> > On 6/6/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
> > >
> > > Sorry for the 1950's Horror Movie Catchphrase. I'm just
odd like that.
> ;-)
> > >
> > >
elt <[EMAIL PROTECTED]> wrote:
> > >
> > > Sorry for the 1950's Horror Movie Catchphrase. I'm just odd
like that.
> ;-)
> > >
> > > The following has been filed as
> http://jira.codehaus.org/browse/MNG-3038
> > > and I encourage
>
> > On 6/6/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
> > >
> > > Sorry for the 1950's Horror Movie Catchphrase. I'm just odd
like that.
> ;-)
> > >
> > > The following has been filed as
> http://jira.codehaus.org/browse/MNG-303
st
Subject: Re: When There's No More Room In Jiragoon, The Closed Will Walk
Among Us: Dawn of the MNG-1577!
I'm still not 100% sure that's the case.
I am working from the point of view of Archiva on this.
And in that case, the versioning of the various maven-* artifacts are
importan
on D.
> >
> >
> > On 6/6/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
> > >
> > > Sorry for the 1950's Horror Movie Catchphrase. I'm just odd
like that.
> ;-)
> > >
> > > The following has been filed as
> http://jira.c
res which
> version
> > of D it gets, because it has no direct dependency on D.
> >
> >
> > On 6/6/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
> > >
> > > Sorry for the 1950's Horror Movie Catchphrase. I'm just odd like
that.
>
Ultimately the short answer is who cares what 2.0.x does.
Why?
Because we didn't write the spec first and anything that has been
done has been embodied in code and subject to changes like MNG-1577.
We need a spec, define the behavior and then write to that. Trying to
do anything wit
; and I encourage discussion on this.
> > >
> > > I was recently working out some discrepancies between what maven
> client,
> > > mpir and archiva show as dependency tree's on some projects, and
> > > discovered something.
> > >
> > > MNG-15
dehaus.org/browse/MNG-3038
> > and I encourage discussion on this.
> >
> > I was recently working out some discrepancies between what maven
client,
> > mpir and archiva show as dependency tree's on some projects, and
> > discovered something.
> >
> > M
st odd like that. ;-)
>
> The following has been filed as http://jira.codehaus.org/browse/MNG-3038
> and I encourage discussion on this.
>
> I was recently working out some discrepancies between what maven client,
> mpir and archiva show as dependency tree's on some project
y tree's on some projects, and
discovered something.
MNG-1577 as discussed isn't done (yet).
I created the teeny example project following the example that Carlos
described on
http://www.nabble.com/Re%3A--vote--MNG-1577-as-the-default-behavior-p9506667s177.html
| What about this use
working out some discrepancies between what maven client,
mpir and archiva show as dependency tree's on some projects, and
discovered something.
MNG-1577 as discussed isn't done (yet).
I created the teeny example project following the example that Carlos
described on
http://www.nabble
phrase. I'm just odd like that. ;-)
The following has been filed as http://jira.codehaus.org/browse/MNG-3038
and I encourage discussion on this.
I was recently working out some discrepancies between what maven client,
mpir and archiva show as dependency tree's on some projects, and
disco
dependency tree's on some projects, and
discovered something.
MNG-1577 as discussed isn't done (yet).
I created the teeny example project following the example that Carlos
described on
http://www.nabble.com/Re%3A--vote--MNG-1577-as-the-default-behavior-p9506667s177.html
| What abo
Jason van Zyl wrote:
On 20 Mar 07, at 7:45 AM 20 Mar 07, Trygve Laugstøl wrote:
Jason van Zyl wrote:
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
On 20 Mar 07, at 7:45 AM 20 Mar 07, Trygve Laugstøl wrote:
Jason van Zyl wrote:
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
Jason van Zyl wrote:
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 broken. To are totally prey to any
Hi Brian,
Brian E. Fox wrote on Saturday, March 17, 2007 6:11 AM:
> 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
i'm -0 about having it in 2.0.6
I still think this is the kind of thing that would make sense in a 2.1
release having into account our version guidelines.
On 3/18/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Brett, Carlos,
Have you looked at the issue/code and do your -1s still hold or can
we
On 18 Mar 07, at 6:24 PM 18 Mar 07, Brett Porter wrote:
Yes, I'm happy with where we got to with the discussion and
withdraw that. I don't think it landing in 2.0.6 is ideal, but I
think it's the best solution available to us today.
(sorry, got confused about the process - thought my -1 wa
Yes, I'm happy with where we got to with the discussion and withdraw
that. I don't think it landing in 2.0.6 is ideal, but I think it's
the best solution available to us today.
(sorry, got confused about the process - thought my -1 was only a
vote, not a veto)
On 19/03/2007, at 9:19 AM, J
Brett, Carlos,
Have you looked at the issue/code and do your -1s still hold or can
we put this through in the 2.0.6 release?
Carlos you did not specifically use -1, but I consider your object to
be the same.
I would like to stage a build for people to try.
Jason.
---
gt : 1.5
[INFO] Resolved: 1.7
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 17, 2007 1:14 AM
To: Maven Developers List
Subject: RE: Mojo to test for MNG-1577 was [vote] MNG-1577 as the
default behavior
I meant to say:
It currently skips sn
Jason van Zyl wrote:
The depMan declarations now channels all transitive dependency to what
the user specifies, but what we still need in the future when ranges
become common place is the conflict resolution mechanism as we've
always thought it would work. Because the overwhelming majority
See Below
Brett Porter wrote:
I'm generally in favour now, but there are a couple of things I'd
still like to explore first, please bear with me.
Having had the chance to review the new behaviour, I can't see any
problems with applying it to current builds - I would expect it
extremely rare
On 17 Mar 07, at 8:34 AM 17 Mar 07, Brett Porter wrote:
I'm generally in favour now, but there are a couple of things I'd
still like to explore first, please bear with me.
Having had the chance to review the new behaviour, I can't see any
problems with applying it to current builds - I wou
I'm generally in favour now, but there are a couple of things I'd
still like to explore first, please bear with me.
Having had the chance to review the new behaviour, I can't see any
problems with applying it to current builds - I would expect it
extremely rare to see a managed dependency i
On 17/03/2007, at 1:37 AM, Jason van Zyl wrote:
No matter how bad the existing behaviour, it is consistent once in
place.
It's not consistent at all. It is totally erratic behavior,
completely defective and counter intuitive. All people are forced
to do is is continually override depende
Eric Redmond wrote:
+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.
+1
Jorg
how you accurately control what versions get pulled in. Ralph, I
would certainly work with you to make an APT or Confluence
document. Wherever is fine with me.
jason.
I've attached a new patch to mng-1577. It contains a patch to a
couple of the APT files for the web site. Please feel
certainly work with you to make an APT or Confluence document.
Wherever is fine with me.
jason.
I've attached a new patch to mng-1577. It contains a patch to a couple
of the APT files for the web site. Please feel free to edit it if I have
gotten something wrong. I've built the site wi
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 d
currently skips snapshots but any released artifacts that
don't match will cause a problem.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Friday, March 16, 2007 7:39 PM
To: Maven Developers List
Subject: Re: [vote] MNG-1577 as the default behavior
Mike,
Goo
if anyone disagrees after looking at the old
versus new behavior. That said, if it gets vetoed then I was thinking
a property in the POM that could get picked up.
When I wrote the patch for MNG-1577 I added an override element to
the dependencyManagement element in the pom so backward
com
n the
top-level POM. We can't jump from 2.0.6 to a 2.1 for this.
Jason.
Jason,
I would take the override option off the table.
When I wrote the patch for MNG-1577 I added an override element to the
dependencyManagement element in the pom so backward compatibility could
be preserved.
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
would mean we still
have to support 2.0.x, and 2.1, which is no different from 2.0.x
except for MNG-1577, and the 2.1, what is now 2.1.
That's not an option either, since this little issue, although higly debated,
does not warrant a minor version update. yes, it changes behaviour. But fixing
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
uce a change we should label it appropriately...
fabrizio
On 3/16/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
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 th
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
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
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
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
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
s.
Jason.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Carlos
Sanchez
Sent: Friday, March 16, 2007 2:47 PM
To: Maven Developers List
Subject: Re: [vote] MNG-1577 as the default behavior
it's not unpredictable at all, it is pretty clear
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
Sent: Friday, March 16, 2007 2:47 PM
To: Maven Developers List
Subject: Re: [vote] MNG-1577 as the default behavior
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 de
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.
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Friday, March 16, 2007 2:29 PM
To: dev@maven.apache.org
Subject: Re: [vote] MNG-1577 as the default behavior
I agree. Anything that makes a "unpredictable behavior" predictable is
a bug fix that should go in a patch. We've had to do
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
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:
>
stone releases instead.
- Brett
On 16/03/2007, at 11:33 AM, Jason van Zyl wrote:
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
>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
leviates much pain
for the vast majority of users.
Jason.
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Friday, March 16, 2007 10:33 AM
To: Maven Developers List
Subject: Re: [vote] MNG-1577 as the default behavior
I'm +1.
I don't think that making depe
until they debugged the problem that they found out it was already
fixed, it just wasn't enabled?
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Friday, March 16, 2007 10:33 AM
To: Maven Developers List
Subject: Re: [vote] MNG-1577 as the default behavior
I'
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.
tance.
All it will do is allow people to align all the versions from the
parent POM. With MNG-1577 they can stop doing this. Mike has seen
this in action in his builds, and I just corrected a build in what
seemed a hopeless situation with the new behavior. There's nothing
consistent a
to trust point releases are safe upgrades.
Let's
> > start moving on putting out 2.1 milestone releases instead.
> >
> > - Brett
> >
> > On 16/03/2007, at 11:33 AM, Jason van Zyl wrote:
> >
> >> Hi,
> >>
> >> After working with it a
On 16/03/2007, at 11:33 AM, Jason van Zyl wrote:
>
>> 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 behavio
van Zyl wrote:
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 broken. To are totally prey to any dependency
introd
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.
ble to trust point releases are safe upgrades. Let's
start moving on putting out 2.1 milestone releases instead.
- Brett
On 16/03/2007, at 11:33 AM, Jason van Zyl wrote:
Hi,
After working with it a little this week I would like to propose to
make MNG-1577 behavior introduced the default
n that instance.
Our users must be able to trust point releases are safe upgrades.
Let's start moving on putting out 2.1 milestone releases instead.
- Brett
On 16/03/2007, at 11:33 AM, Jason van Zyl wrote:
Hi,
After working with it a little this week I would like to propose to
ma
n Developers List
> Objet : Re: [vote] MNG-1577 as the default behavior
>
> +1
>
> Emmanuel
>
> Jason van Zyl a écrit :
> > Hi,
> >
> > After working with it a little this week I would like to propose to
> > make
> > MNG-1577 behavior introduc
is 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 broken. To are totally prey to
any dependency introduced by a dependency which makes no sense and
+1
Emmanuel
Jason van Zyl a écrit :
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 broken. To are totally
gt; 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 broken. To are tota
't beaten me to it, I'd be happy to do this as I promised
(hoping they will review it of course).
Ralph
Jason van Zyl wrote:
> 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
&
e to it, I'd be happy to do this as I promised
(hoping they will review it of course).
Ralph
Jason van Zyl wrote:
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 withou
Well, obviously I would have no objection. ;-)
+1
Ralph
Jason van Zyl wrote:
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
I can attest to this being a major issue for complex builds. Without
this behavior, it's nearly impossible to manage the build of complex
projects.
-Nathan
On 3/15/07, Mike Perham <[EMAIL PROTECTED]> wrote:
A will get D 2.0. Yes, our build depends heavily on this behavior.
I'm ok with it goin
A will get D 2.0. Yes, our build depends heavily on this behavior.
I'm ok with it going into 2.0.6 as long as it is noted in the release
notes. Based on the number of votes the issue has, this is a major
problem for a lot of people. I can't imagine any reasonably sized
build which has not enco
PROTECTED]> wrote:
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 broken. To are totally prey to any depend
I can think of some cases where it might break a build, but most of them
are where a transitive dependency creeps into a build because the user
assumes that MNG-1577 is how it's always worked. That being said, these
issues would be easily remedied since you now have more control, and
anyone
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 broken. To are totally prey to any dependency
introduced by
On 2 Mar 07, at 8:27 AM 2 Mar 07, Mike Perham wrote:
I believe the patch is very very similar for the branch but the
sandbox code was for the trunk code as of a few weeks ago. Patrick is
out on vacation this week and back on Monday. I know we found two
bugs in the patch while using it interna
I believe the patch is very very similar for the branch but the
sandbox code was for the trunk code as of a few weeks ago. Patrick is
out on vacation this week and back on Monday. I know we found two
bugs in the patch while using it internally over the last month that
are not fixed in the sandbo
s in the short term will demonstrate we're correcting
the problems as fast as possible.
I'm am still going to try and round up the necessary help and
encourage folks to help get 2.0.6 out before March 14th as I stated
when 2.0.5 was released.
I will back port MNG-1577 myself if
1 - 100 of 113 matches
Mail list logo
