Mark,
I added more files to MNG-3351 (since I'm not sure what will be needed).
This issue also relates to MIDEA-84 (I don't know if you use IntelliJ or
not).
Regards,
-Dave
dhoffer wrote:
>
> Mark,
>
> That sounds wonderful. I want to help any way I can!
>
> I
is again so hopefully we can wrap this up once
> and for all. I'm just getting back up to speed with this issue on the
> latest maven and release plugin, so any relevant findings would be
> welcome.
>
> Cheers,
>
> Mark
>
> On 19/01/2008, dhoffer <[EMAIL PROTECTE
vior with 2.0.8.)
-Dave
dhoffer wrote:
>
> We are at a critical point with our usage of maven. We cannot update to
> 2.0.8 because 2.0.8 is broken with respect to the release plugin; RE
> MNG-3351 (no releases are possible if using version ranges).
>
> However we need to up
I feel this is the most important bug that needs to be fixed. We make heavy
use of version ranges and without this fix they are unusable (we have to
manually apply a patch to each maven release).
"1) You wish a release build with no snapshots which is the normal behaviour
and so you just build t
"..It's crazy that version ranges are still unusable in 2.0.8.."
Exactly, we really need this fixed, can we apply this patch so we can use
version ranges and snapshots. This issue is killing us.
-Dave
mihobson wrote:
>
> On 10/01/2008, Michael McCallum <[EMAIL PROTECTED]> wrote:
>> another th
We are at a critical point with our usage of maven. We cannot update to
2.0.8 because 2.0.8 is broken with respect to the release plugin; RE
MNG-3351 (no releases are possible if using version ranges).
However we need to upgrade to 2.0.8 because we now have large projects that
are tripping all
Does maven-enforcer-plugin just stop a build from including a snapshot or
does it force it to find a release? You know what I mean? Is it a
after-the-fact filter or does it change the behavior of maven?
Michael McCallum-3 wrote:
>
> On Wed, 09 Jan 2008 15:15:55 Michael McCallum wrote:
>> > I
We have thought about this but since it cannot prevent local snapshots it is
not really a solution only a technique to limit the problem. BTW, we use
TeamCity for CI, builds get farmed out to many build agents so what is in
their local repo is quite random; sometimes it works sometimes it doesn't
"...But at the same time I would never want another department to break my
build
by deploying a snapshot I'm not ready for. "
IMHO, I think our approach excels in making sure this doesn't happen. First
and foremost, if this version range issue can be fixed, snapshots will never
be considered val
atter to you? I do and with them version ranges is broken, lets fix it
and we both get what we want. I don't understand the last statement 'You
run the risk of breaking builds otherwise.'
Michael McCallum-3 wrote:
>
> On Tue, 08 Jan 2008 14:25:06 dhoffer wrote:
>> R
atched
> a
> change to a library deployed into production
>
>
> On Tue, 08 Jan 2008 07:13:42 dhoffer wrote:
>> Which maven release/build is this in?
>>
>> Based on my understanding I don't think this is sufficient to resolve
>> this
>> issue. It
h will stop 1.1-SNAPSHOT from
> being
> included, this wont stop 1.0.4-SNAPSHOT but i think thats valid anyway...
>
>
> On Sun, 06 Jan 2008 14:39:37 dhoffer wrote:
>> What is the status of this? This issue is very serious (highest
>> priority)
>> for us; every t
What is the status of this? This issue is very serious (highest priority)
for us; every time we update maven we have to apply a patch to fix this else
releases fail.
Can we come to some conclusion on how to fix this?
-Dave
mihobson wrote:
>
> Hi,
>
> Whilst attempting to fix MNG-2994,
...be sure to cast your ballot for MNG-3092:)
ossi petz-2 wrote:
>
> hallo
>
> i would like to add one vote to exclude snapshots from version ranges
> that do not declare them.
>
> we encounter two problematic situations:
>
> when using the release plugin we need to clean the local reposit
>Quote:
I think snapshots are a different aspect, outside of version ranges. Version
ranges are meant to specify a range of versions. Snapshots fit perfectly
in a version range.
>
The problem with the statement that 'snapshots fit perfectly in a version
range' is that it missing the point. You ar
You can't fix this by disallowing repos because snapshots may be in the local
repo.
Max O Bowsher wrote:
>
> Kenney Westerhof wrote:
>>
>>
>> Patrick Schneider wrote:
>>> For now, I'm a fan of disallowing snapshots when they are not
>>> explicitly in
>>> the boundary, as per the patch.
>>>
>>
This approach will not work because one would then have to continually
specify what snapshots to exclude. We use version ranges to specify the
range of valid released versions. I.e. when building get the latest
released version (in most all cases). What is need is to somehow disallow
all snapsh
Plugins seem to resolve version ranges in an inconsistent manor. If I have a
dependency version specified as [1.0,) how should this be resolved with
respect to SNAPSHOTS (in the opinion of the maven2 developers)?
Test case: Assume you have released versions 1.0, 1.1, 1.2, 1.3, 1.4 & 1.5.
In ad
18 matches
Mail list logo
