I guess we have to agree to disagree on this.
Regardless of what the decision is... I sure hope the decision made...
and published.... soon.
vbk
On 09/01/09 00:34, Paul Sandoz wrote:
>
> On Sep 1, 2009, at 12:56 AM, Vince Kraemer wrote:
>
>> On 08/31/09 13:19, Paul Sandoz wrote:
>>>
>>> On Aug 31, 2009, at 7:16 PM, Vince Kraemer wrote:
>>>
>>>> How do you suggest we serve the users that want to merge the new
>>>> bits over a previous install?
>>>>
>>>
>>> Zip files are not really an appropriate mechanism for directly
>>> upgrading existing software bits.
>>>
>>> Here are five prominent zip files:
>>>
>>> http://apache.multidist.com/ant/binaries/apache-ant-1.7.1-bin.zip
>>>
>>> http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-2.2.1-bin.zip
>>>
>>>
>>> http://apache.cict.fr/tomcat/tomcat-6/v6.0.20/bin/apache-tomcat-6.0.20.zip
>>>
>>>
>>> http://sourceforge.net/projects/jboss/files/JBoss/JBoss-5.1.0.GA/jboss-5.1.0.GA-jdk6.zip/download
>>>
>>>
>>> http://s3.amazonaws.com/dist.springframework.org/snapshot/SPR/spring-framework-3.0.0.CI-207.zip
>>>
>>>
>>> How many of the above unzip into a directory without the version
>>> present?
>>
>> None of the 'release' zips unzip into a directory without an embedded
>> version.
>
> The last one is not a release zip.
>
> The points is that pattern is the *expected* pattern for zip downloads
> and GF is taking a different approach that users will not expect: the
> zip name is different from the directory where the contents are
> unzipped to. It breaks the rule of least surprise.
>
>
>> And none of them would be suitable to merge new bits over a previous
>> 'install' from their nightly counter part (if it existed).
>>
>
> Zip archive is not really suitable for that. Older artifacts not
> present in newer builds would not be removed.
>
>
>> So, what should our users that want to unzip today's build over
>> yesterday's build do?
>>
>
> Delete the old one, unzip the new one, rename it. Or use something
> else is more suitable for upgrading *existing* software bits.
>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>