You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Jason van Zyl (JIRA)" <ji...@codehaus.org> on 2007/11/06 06:23:35 UTC
[jira] Created: (MARTIFACT-6) The deployer should detect previous
deployments of the same version and die if that's the case.
The deployer should detect previous deployments of the same version and die if that's the case.
-----------------------------------------------------------------------------------------------
Key: MARTIFACT-6
URL: http://jira.codehaus.org/browse/MARTIFACT-6
Project: Maven Artifact
Issue Type: Improvement
Affects Versions: 3.0-alpha-1
Reporter: Jason van Zyl
We simply have to die because giving people an option is just going to let them continue with their bad practices. If you let the redeployment of released binaries then it will happen, and it will cause problems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
Posted by Brett Porter <br...@apache.org>.
On 06/11/2007, at 4:42 PM, Jason van Zyl wrote:
> They die.
>
> How that non unique stuff creep in should be looked at. As a short
> term convenience for not having to wipe stuff out is far less
> important in that you can hose an entire team. Most people nuke the
> snapshots after a couple weeks but in that period no one can lock
> down to anything and you potentially hose a lot of people.
>
> If we actually get it to work in 2.0.x then some mode for allowing
> that could be added but it's a terrible practice to have non-unique
> snapshots. So it didn't occur to me because I tell people to never
> use that feature unless they enjoy wasting their time figuring how
> to roll back to something stable. It's another "the convenience
> doesn't out weight the dire consequences".
-1 to this.
As much as I continue to recommend the same thing, I know people use
these in different ways (eg, just having the latest 500mb EAR file
available in the repository) that would make it silly to remove the
functionality under the assumption that we know better what their
requirements are.
You already have to find the setting buried in the documentation,
let's just bury the associated explanation as to why you should use
pinnable snapshots right on top of it.
Cheers,
Brett
>
> On 5 Nov 07, at 9:26 PM 5 Nov 07, Brett Porter wrote:
>
>> What about non-unique-versioned snapshots?
>>
>> - Brett
>>
>> On 06/11/2007, at 4:23 PM, Jason van Zyl (JIRA) wrote:
>>
>>> The deployer should detect previous deployments of the same
>>> version and die if that's the case.
>>> --------------------------------------------------------------------
>>> ---------------------------
>>>
>>> Key: MARTIFACT-6
>>> URL: http://jira.codehaus.org/browse/MARTIFACT-6
>>> Project: Maven Artifact
>>> Issue Type: Improvement
>>> Affects Versions: 3.0-alpha-1
>>> Reporter: Jason van Zyl
>>>
>>>
>>> We simply have to die because giving people an option is just
>>> going to let them continue with their bad practices. If you let
>>> the redeployment of released binaries then it will happen, and it
>>> will cause problems.
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> If you think it was sent incorrectly contact one of the
>>> administrators: http://jira.codehaus.org/secure/Administrators.jspa
>>> -
>>> For more information on JIRA, see: http://www.atlassian.com/
>>> software/jira
>>>
>>>
>>
>> --
>> Brett Porter - brett@apache.org
>> Blog: http://www.devzuz.org/blogs/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>it's bad when a bunch of those
>"freedoms" kick in to bite you in the ass in the same week, which is
>usually the case, it's just hard to defend Maven's position as a
>standard, reliable build tool. In every case there is a decision point
>like this we should take the path of least potential hindrance to a
>teams productivity.
As the creator of the Iron fist of Maven (enforcer) I can hardly argue
with that logic. Touche.
--Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
Posted by Jason van Zyl <ja...@maven.org>.
On 6 Nov 07, at 4:58 AM 6 Nov 07, Brian E. Fox wrote:
> I agree with that. I think the point is that both are valid use cases.
Problems in both can stop teams in their tracks, but snapshots
overflowing on your machine is really a maintenance issue where not
providing a path to use is something we're allowing which I think is
bad. For everything little "freedom" we allow it is an avenue to do
something that will lead to an instability. I just think this is
unnecessary. When it does go wrong it's bad when a bunch of those
"freedoms" kick in to bite you in the ass in the same week, which is
usually the case, it's just hard to defend Maven's position as a
standard, reliable build tool. In every case there is a decision point
like this we should take the path of least potential hindrance to a
teams productivity.
>
> Although if my repo manager supported the cleanup, I would more than
> likely use uniqueversions even if I didn't intend to use them, just in
> case.
>
> -----Original Message-----
> From: Jason van Zyl [mailto:jason@maven.org]
> Sent: Tuesday, November 06, 2007 8:39 AM
> To: Maven Developers List
> Subject: Re: [jira] Created: (MARTIFACT-6) The deployer should detect
> previous deployments of the same version and die if that's the case.
>
>
> On 5 Nov 07, at 11:20 PM 5 Nov 07, Brian E. Fox wrote:
>
>> I don't completely agree that non unique should be essentially
>> killed.
>> Unless you are letting people pin to a specific snapshot instance,
>> (which IMO is much worse) there are no problems using the non unique
>> stuff. We switched to it because we were using up over 300gb / week
>> from
>> our continuous integration builds.
>>
>
> That stuff is easily culled, and sometimes you simply need to lock to
> a version while the rest of the team converges after a hiccup. It
> maybe only be a day, but a half day lost to farting around is
> pointless.
>
>> I think worse problems crop up when people start hand picking their
>> snapshot versions. This might be ok for OSS but internal commercial,
>> if
>> the latest isn't working, I want to know it and I want it fixed asap.
>
> I've found it necessary at times to lock down and if something has
> changed in the code it should be represented as something changed in
> the repository. It's really not a technical feat to run a scheduled
> job to clean up after snapshot production. In practical terms a window
> of three days in a rapidly changing system is enough when used in
> conjunction with nightly builds and team integration builds.
>
>>
>>
>> --Brian
>>
>> -----Original Message-----
>> From: Jason van Zyl [mailto:jason@maven.org]
>> Sent: Tuesday, November 06, 2007 6:42 AM
>> To: Maven Developers List
>> Subject: Re: [jira] Created: (MARTIFACT-6) The deployer should detect
>> previous deployments of the same version and die if that's the case.
>>
>> They die.
>>
>> How that non unique stuff creep in should be looked at. As a short
>> term convenience for not having to wipe stuff out is far less
>> important in that you can hose an entire team. Most people nuke the
>> snapshots after a couple weeks but in that period no one can lock
>> down
>> to anything and you potentially hose a lot of people.
>>
>> If we actually get it to work in 2.0.x then some mode for allowing
>> that could be added but it's a terrible practice to have non-unique
>> snapshots. So it didn't occur to me because I tell people to never
>> use
>> that feature unless they enjoy wasting their time figuring how to
>> roll
>> back to something stable. It's another "the convenience doesn't out
>> weight the dire consequences".
>>
>> On 5 Nov 07, at 9:26 PM 5 Nov 07, Brett Porter wrote:
>>
>>> What about non-unique-versioned snapshots?
>>>
>>> - Brett
>>>
>>> On 06/11/2007, at 4:23 PM, Jason van Zyl (JIRA) wrote:
>>>
>>>> The deployer should detect previous deployments of the same version
>>>> and die if that's the case.
>>>>
>>
> ------------------------------------------------------------------------
>> -----------------------
>>>>
>>>> Key: MARTIFACT-6
>>>> URL: http://jira.codehaus.org/browse/MARTIFACT-6
>>>> Project: Maven Artifact
>>>> Issue Type: Improvement
>>>> Affects Versions: 3.0-alpha-1
>>>> Reporter: Jason van Zyl
>>>>
>>>>
>>>> We simply have to die because giving people an option is just going
>>>> to let them continue with their bad practices. If you let the
>>>> redeployment of released binaries then it will happen, and it will
>>>> cause problems.
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> -
>>>> If you think it was sent incorrectly contact one of the
>>>> administrators: http://jira.codehaus.org/secure/Administrators.jspa
>>>> -
>>>> For more information on JIRA, see:
>> http://www.atlassian.com/software/jira
>>>>
>>>>
>>>
>>> --
>>> Brett Porter - brett@apache.org
>>> Blog: http://www.devzuz.org/blogs/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I agree with that. I think the point is that both are valid use cases.
Although if my repo manager supported the cleanup, I would more than
likely use uniqueversions even if I didn't intend to use them, just in
case.
-----Original Message-----
From: Jason van Zyl [mailto:jason@maven.org]
Sent: Tuesday, November 06, 2007 8:39 AM
To: Maven Developers List
Subject: Re: [jira] Created: (MARTIFACT-6) The deployer should detect
previous deployments of the same version and die if that's the case.
On 5 Nov 07, at 11:20 PM 5 Nov 07, Brian E. Fox wrote:
> I don't completely agree that non unique should be essentially killed.
> Unless you are letting people pin to a specific snapshot instance,
> (which IMO is much worse) there are no problems using the non unique
> stuff. We switched to it because we were using up over 300gb / week
> from
> our continuous integration builds.
>
That stuff is easily culled, and sometimes you simply need to lock to
a version while the rest of the team converges after a hiccup. It
maybe only be a day, but a half day lost to farting around is pointless.
> I think worse problems crop up when people start hand picking their
> snapshot versions. This might be ok for OSS but internal commercial,
> if
> the latest isn't working, I want to know it and I want it fixed asap.
I've found it necessary at times to lock down and if something has
changed in the code it should be represented as something changed in
the repository. It's really not a technical feat to run a scheduled
job to clean up after snapshot production. In practical terms a window
of three days in a rapidly changing system is enough when used in
conjunction with nightly builds and team integration builds.
>
>
> --Brian
>
> -----Original Message-----
> From: Jason van Zyl [mailto:jason@maven.org]
> Sent: Tuesday, November 06, 2007 6:42 AM
> To: Maven Developers List
> Subject: Re: [jira] Created: (MARTIFACT-6) The deployer should detect
> previous deployments of the same version and die if that's the case.
>
> They die.
>
> How that non unique stuff creep in should be looked at. As a short
> term convenience for not having to wipe stuff out is far less
> important in that you can hose an entire team. Most people nuke the
> snapshots after a couple weeks but in that period no one can lock down
> to anything and you potentially hose a lot of people.
>
> If we actually get it to work in 2.0.x then some mode for allowing
> that could be added but it's a terrible practice to have non-unique
> snapshots. So it didn't occur to me because I tell people to never use
> that feature unless they enjoy wasting their time figuring how to roll
> back to something stable. It's another "the convenience doesn't out
> weight the dire consequences".
>
> On 5 Nov 07, at 9:26 PM 5 Nov 07, Brett Porter wrote:
>
>> What about non-unique-versioned snapshots?
>>
>> - Brett
>>
>> On 06/11/2007, at 4:23 PM, Jason van Zyl (JIRA) wrote:
>>
>>> The deployer should detect previous deployments of the same version
>>> and die if that's the case.
>>>
>
------------------------------------------------------------------------
> -----------------------
>>>
>>> Key: MARTIFACT-6
>>> URL: http://jira.codehaus.org/browse/MARTIFACT-6
>>> Project: Maven Artifact
>>> Issue Type: Improvement
>>> Affects Versions: 3.0-alpha-1
>>> Reporter: Jason van Zyl
>>>
>>>
>>> We simply have to die because giving people an option is just going
>>> to let them continue with their bad practices. If you let the
>>> redeployment of released binaries then it will happen, and it will
>>> cause problems.
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> If you think it was sent incorrectly contact one of the
>>> administrators: http://jira.codehaus.org/secure/Administrators.jspa
>>> -
>>> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>>>
>>>
>>
>> --
>> Brett Porter - brett@apache.org
>> Blog: http://www.devzuz.org/blogs/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
Posted by Jason van Zyl <ja...@maven.org>.
On 5 Nov 07, at 11:20 PM 5 Nov 07, Brian E. Fox wrote:
> I don't completely agree that non unique should be essentially killed.
> Unless you are letting people pin to a specific snapshot instance,
> (which IMO is much worse) there are no problems using the non unique
> stuff. We switched to it because we were using up over 300gb / week
> from
> our continuous integration builds.
>
That stuff is easily culled, and sometimes you simply need to lock to
a version while the rest of the team converges after a hiccup. It
maybe only be a day, but a half day lost to farting around is pointless.
> I think worse problems crop up when people start hand picking their
> snapshot versions. This might be ok for OSS but internal commercial,
> if
> the latest isn't working, I want to know it and I want it fixed asap.
I've found it necessary at times to lock down and if something has
changed in the code it should be represented as something changed in
the repository. It's really not a technical feat to run a scheduled
job to clean up after snapshot production. In practical terms a window
of three days in a rapidly changing system is enough when used in
conjunction with nightly builds and team integration builds.
>
>
> --Brian
>
> -----Original Message-----
> From: Jason van Zyl [mailto:jason@maven.org]
> Sent: Tuesday, November 06, 2007 6:42 AM
> To: Maven Developers List
> Subject: Re: [jira] Created: (MARTIFACT-6) The deployer should detect
> previous deployments of the same version and die if that's the case.
>
> They die.
>
> How that non unique stuff creep in should be looked at. As a short
> term convenience for not having to wipe stuff out is far less
> important in that you can hose an entire team. Most people nuke the
> snapshots after a couple weeks but in that period no one can lock down
> to anything and you potentially hose a lot of people.
>
> If we actually get it to work in 2.0.x then some mode for allowing
> that could be added but it's a terrible practice to have non-unique
> snapshots. So it didn't occur to me because I tell people to never use
> that feature unless they enjoy wasting their time figuring how to roll
> back to something stable. It's another "the convenience doesn't out
> weight the dire consequences".
>
> On 5 Nov 07, at 9:26 PM 5 Nov 07, Brett Porter wrote:
>
>> What about non-unique-versioned snapshots?
>>
>> - Brett
>>
>> On 06/11/2007, at 4:23 PM, Jason van Zyl (JIRA) wrote:
>>
>>> The deployer should detect previous deployments of the same version
>>> and die if that's the case.
>>>
> ------------------------------------------------------------------------
> -----------------------
>>>
>>> Key: MARTIFACT-6
>>> URL: http://jira.codehaus.org/browse/MARTIFACT-6
>>> Project: Maven Artifact
>>> Issue Type: Improvement
>>> Affects Versions: 3.0-alpha-1
>>> Reporter: Jason van Zyl
>>>
>>>
>>> We simply have to die because giving people an option is just going
>>> to let them continue with their bad practices. If you let the
>>> redeployment of released binaries then it will happen, and it will
>>> cause problems.
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> If you think it was sent incorrectly contact one of the
>>> administrators: http://jira.codehaus.org/secure/Administrators.jspa
>>> -
>>> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>>>
>>>
>>
>> --
>> Brett Porter - brett@apache.org
>> Blog: http://www.devzuz.org/blogs/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I don't completely agree that non unique should be essentially killed.
Unless you are letting people pin to a specific snapshot instance,
(which IMO is much worse) there are no problems using the non unique
stuff. We switched to it because we were using up over 300gb / week from
our continuous integration builds.
I think worse problems crop up when people start hand picking their
snapshot versions. This might be ok for OSS but internal commercial, if
the latest isn't working, I want to know it and I want it fixed asap.
--Brian
-----Original Message-----
From: Jason van Zyl [mailto:jason@maven.org]
Sent: Tuesday, November 06, 2007 6:42 AM
To: Maven Developers List
Subject: Re: [jira] Created: (MARTIFACT-6) The deployer should detect
previous deployments of the same version and die if that's the case.
They die.
How that non unique stuff creep in should be looked at. As a short
term convenience for not having to wipe stuff out is far less
important in that you can hose an entire team. Most people nuke the
snapshots after a couple weeks but in that period no one can lock down
to anything and you potentially hose a lot of people.
If we actually get it to work in 2.0.x then some mode for allowing
that could be added but it's a terrible practice to have non-unique
snapshots. So it didn't occur to me because I tell people to never use
that feature unless they enjoy wasting their time figuring how to roll
back to something stable. It's another "the convenience doesn't out
weight the dire consequences".
On 5 Nov 07, at 9:26 PM 5 Nov 07, Brett Porter wrote:
> What about non-unique-versioned snapshots?
>
> - Brett
>
> On 06/11/2007, at 4:23 PM, Jason van Zyl (JIRA) wrote:
>
>> The deployer should detect previous deployments of the same version
>> and die if that's the case.
>>
------------------------------------------------------------------------
-----------------------
>>
>> Key: MARTIFACT-6
>> URL: http://jira.codehaus.org/browse/MARTIFACT-6
>> Project: Maven Artifact
>> Issue Type: Improvement
>> Affects Versions: 3.0-alpha-1
>> Reporter: Jason van Zyl
>>
>>
>> We simply have to die because giving people an option is just going
>> to let them continue with their bad practices. If you let the
>> redeployment of released binaries then it will happen, and it will
>> cause problems.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the
>> administrators: http://jira.codehaus.org/secure/Administrators.jspa
>> -
>> For more information on JIRA, see:
http://www.atlassian.com/software/jira
>>
>>
>
> --
> Brett Porter - brett@apache.org
> Blog: http://www.devzuz.org/blogs/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
Posted by Jason van Zyl <ja...@maven.org>.
They die.
How that non unique stuff creep in should be looked at. As a short
term convenience for not having to wipe stuff out is far less
important in that you can hose an entire team. Most people nuke the
snapshots after a couple weeks but in that period no one can lock down
to anything and you potentially hose a lot of people.
If we actually get it to work in 2.0.x then some mode for allowing
that could be added but it's a terrible practice to have non-unique
snapshots. So it didn't occur to me because I tell people to never use
that feature unless they enjoy wasting their time figuring how to roll
back to something stable. It's another "the convenience doesn't out
weight the dire consequences".
On 5 Nov 07, at 9:26 PM 5 Nov 07, Brett Porter wrote:
> What about non-unique-versioned snapshots?
>
> - Brett
>
> On 06/11/2007, at 4:23 PM, Jason van Zyl (JIRA) wrote:
>
>> The deployer should detect previous deployments of the same version
>> and die if that's the case.
>> -----------------------------------------------------------------------------------------------
>>
>> Key: MARTIFACT-6
>> URL: http://jira.codehaus.org/browse/MARTIFACT-6
>> Project: Maven Artifact
>> Issue Type: Improvement
>> Affects Versions: 3.0-alpha-1
>> Reporter: Jason van Zyl
>>
>>
>> We simply have to die because giving people an option is just going
>> to let them continue with their bad practices. If you let the
>> redeployment of released binaries then it will happen, and it will
>> cause problems.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the
>> administrators: http://jira.codehaus.org/secure/Administrators.jspa
>> -
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>
>
> --
> Brett Porter - brett@apache.org
> Blog: http://www.devzuz.org/blogs/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
Posted by Brett Porter <br...@apache.org>.
What about non-unique-versioned snapshots?
- Brett
On 06/11/2007, at 4:23 PM, Jason van Zyl (JIRA) wrote:
> The deployer should detect previous deployments of the same version
> and die if that's the case.
> ----------------------------------------------------------------------
> -------------------------
>
> Key: MARTIFACT-6
> URL: http://jira.codehaus.org/browse/MARTIFACT-6
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0-alpha-1
> Reporter: Jason van Zyl
>
>
> We simply have to die because giving people an option is just going
> to let them continue with their bad practices. If you let the
> redeployment of released binaries then it will happen, and it will
> cause problems.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the
> administrators: http://jira.codehaus.org/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/
> software/jira
>
>
--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MARTIFACT-6) The deployer should detect previous
deployments of the same version and die if that's the case.
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MARTIFACT-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Porter updated MARTIFACT-6:
---------------------------------
Fix Version/s: (was: 3.0-alpha-1)
> The deployer should detect previous deployments of the same version and die if that's the case.
> -----------------------------------------------------------------------------------------------
>
> Key: MARTIFACT-6
> URL: http://jira.codehaus.org/browse/MARTIFACT-6
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0-alpha-1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
> Attachments: test.zip
>
>
> We simply have to die because giving people an option is just going to let them continue with their bad practices. If you let the redeployment of released binaries then it will happen, and it will cause problems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MNG-4377) The deployer should detect previous
deployments of the same version and die if that's the case.
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Porter moved MARTIFACT-6 to MNG-4377:
-------------------------------------------
Affects Version/s: (was: 3.0-alpha-1)
Workflow: Maven New (was: jira)
Key: MNG-4377 (was: MARTIFACT-6)
Project: Maven 2 (was: Maven Artifact)
> The deployer should detect previous deployments of the same version and die if that's the case.
> -----------------------------------------------------------------------------------------------
>
> Key: MNG-4377
> URL: http://jira.codehaus.org/browse/MNG-4377
> Project: Maven 2
> Issue Type: Improvement
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
> Attachments: test.zip
>
>
> We simply have to die because giving people an option is just going to let them continue with their bad practices. If you let the redeployment of released binaries then it will happen, and it will cause problems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MARTIFACT-6) The deployer should detect previous
deployments of the same version and die if that's the case.
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MARTIFACT-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138943#action_138943 ]
Brett Porter commented on MARTIFACT-6:
--------------------------------------
as it turns out, the current implementation was completely broken anyway, and happily let you deploy twice.
I'll commit my fix for it, but leave this open to make it configurable. It might also be something worth porting to 2.0.10?
> The deployer should detect previous deployments of the same version and die if that's the case.
> -----------------------------------------------------------------------------------------------
>
> Key: MARTIFACT-6
> URL: http://jira.codehaus.org/browse/MARTIFACT-6
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0-alpha-1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
> Fix For: 3.0-alpha-1
>
>
> We simply have to die because giving people an option is just going to let them continue with their bad practices. If you let the redeployment of released binaries then it will happen, and it will cause problems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MARTIFACT-6) The deployer should detect previous
deployments of the same version and die if that's the case.
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MARTIFACT-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Porter reopened MARTIFACT-6:
----------------------------------
This should still be dealt with for non-HTTP repositories IMO.
I'm assuming Mercury will be the front-end facade for those.
> The deployer should detect previous deployments of the same version and die if that's the case.
> -----------------------------------------------------------------------------------------------
>
> Key: MARTIFACT-6
> URL: http://jira.codehaus.org/browse/MARTIFACT-6
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0-alpha-1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
> Fix For: 3.0-alpha-1
>
> Attachments: test.zip
>
>
> We simply have to die because giving people an option is just going to let them continue with their bad practices. If you let the redeployment of released binaries then it will happen, and it will cause problems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MARTIFACT-6) The deployer should detect previous
deployments of the same version and die if that's the case.
Posted by "Igor Fedorenko (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MARTIFACT-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Fedorenko reopened MARTIFACT-6:
------------------------------------
Unfortunately implemented solution does not work for attached release artifacts and as far as I know repository metadata simply does not have any information about such artifacts.
What is worth, current implementation fails deployment of all attached release artifacts with "The artifact was already deployed" error. I am not sure how this got past maven ITs, but it certainly makes current maven 3.0 unusable for me. I will provide trivial/sample project shortly.
> The deployer should detect previous deployments of the same version and die if that's the case.
> -----------------------------------------------------------------------------------------------
>
> Key: MARTIFACT-6
> URL: http://jira.codehaus.org/browse/MARTIFACT-6
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0-alpha-1
> Reporter: Jason van Zyl
> Assignee: Brett Porter
> Fix For: 3.0-alpha-1
>
>
> We simply have to die because giving people an option is just going to let them continue with their bad practices. If you let the redeployment of released binaries then it will happen, and it will cause problems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MARTIFACT-6) The deployer should detect previous
deployments of the same version and die if that's the case.
Posted by "Jason van Zyl (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MARTIFACT-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason van Zyl closed MARTIFACT-6.
---------------------------------
Assignee: Jason van Zyl (was: Brett Porter)
Resolution: Fixed
No one seems to be able to get this logic right and we'll just do it properly in Mercury. I've merged the code into trunk so the facade production will start shortly and maven-artifact will just get phased out.
> The deployer should detect previous deployments of the same version and die if that's the case.
> -----------------------------------------------------------------------------------------------
>
> Key: MARTIFACT-6
> URL: http://jira.codehaus.org/browse/MARTIFACT-6
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0-alpha-1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
> Fix For: 3.0-alpha-1
>
> Attachments: test.zip
>
>
> We simply have to die because giving people an option is just going to let them continue with their bad practices. If you let the redeployment of released binaries then it will happen, and it will cause problems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MARTIFACT-6) The deployer should detect previous
deployments of the same version and die if that's the case.
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MARTIFACT-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Porter closed MARTIFACT-6.
--------------------------------
Assignee: Brett Porter (was: Jason van Zyl)
Resolution: Fixed
> The deployer should detect previous deployments of the same version and die if that's the case.
> -----------------------------------------------------------------------------------------------
>
> Key: MARTIFACT-6
> URL: http://jira.codehaus.org/browse/MARTIFACT-6
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0-alpha-1
> Reporter: Jason van Zyl
> Assignee: Brett Porter
> Fix For: 3.0-alpha-1
>
>
> We simply have to die because giving people an option is just going to let them continue with their bad practices. If you let the redeployment of released binaries then it will happen, and it will cause problems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MARTIFACT-6) The deployer should detect previous
deployments of the same version and die if that's the case.
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MARTIFACT-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Fox reopened MARTIFACT-6:
-------------------------------
This is currently hardcoded and there's no way to override this in the deploy plugin. The original discussion was that deploy could force this to redeploy if we need it to (think of a failed multimodule build where half the artifacts got deployed).
> The deployer should detect previous deployments of the same version and die if that's the case.
> -----------------------------------------------------------------------------------------------
>
> Key: MARTIFACT-6
> URL: http://jira.codehaus.org/browse/MARTIFACT-6
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0-alpha-1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
> Fix For: 3.0-alpha-1
>
>
> We simply have to die because giving people an option is just going to let them continue with their bad practices. If you let the redeployment of released binaries then it will happen, and it will cause problems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MARTIFACT-6) The deployer should detect previous
deployments of the same version and die if that's the case.
Posted by "Igor Fedorenko (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MARTIFACT-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Fedorenko updated MARTIFACT-6:
-----------------------------------
Attachment: test.zip
Sample project that demonstrates the problem. Use {{mvn clean source:jar deploy}} or {{mvn -Passembly clean deploy}} to deploy main and attached artifacts to file:target/repository. This works using maven 2.0.9 but fails with maven 3.0-SNAPSHOT (as of svn rev 688946, to be precise).
> The deployer should detect previous deployments of the same version and die if that's the case.
> -----------------------------------------------------------------------------------------------
>
> Key: MARTIFACT-6
> URL: http://jira.codehaus.org/browse/MARTIFACT-6
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0-alpha-1
> Reporter: Jason van Zyl
> Assignee: Brett Porter
> Fix For: 3.0-alpha-1
>
> Attachments: test.zip
>
>
> We simply have to die because giving people an option is just going to let them continue with their bad practices. If you let the redeployment of released binaries then it will happen, and it will cause problems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MARTIFACT-6) The deployer should detect previous
deployments of the same version and die if that's the case.
Posted by "Jason van Zyl (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MARTIFACT-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason van Zyl closed MARTIFACT-6.
---------------------------------
Resolution: Fixed
Fix Version/s: 3.0-alpha-1
No more redeploy.
> The deployer should detect previous deployments of the same version and die if that's the case.
> -----------------------------------------------------------------------------------------------
>
> Key: MARTIFACT-6
> URL: http://jira.codehaus.org/browse/MARTIFACT-6
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0-alpha-1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
> Fix For: 3.0-alpha-1
>
>
> We simply have to die because giving people an option is just going to let them continue with their bad practices. If you let the redeployment of released binaries then it will happen, and it will cause problems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira