maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@maven.org>
Subject Re: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
Date Tue, 06 Nov 2007 15:39:54 GMT

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


Mime
View raw message