Home » Eclipse Projects » Eclipse Platform » Unzipping eclipse download requires password?!?
| |
| Re: Unzipping eclipse download requires password?!? [message #330735 is a reply to message #330689] |
Tue, 12 August 2008 12:48   |
 Michael Moser
Messages: 914
Registered: July 2009 |
Senior Member |
|
|
Eric Rizzo wrote:
>> ...
> This wiki page,
> http://wiki.eclipse.org/SDK_Known_Issues#Windows_issues explains the
> problems with unzipping on Windows. There is a link to that page on
> the main packages downloads page, but not for some reason on the page
> you were looking at, http://www.eclipse.org/downloads/packages/ I've
> re-opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=169776 to
> (hopefully) correct that.
> Hope this helps,
> Eric
Thanks - it did help. Except for the path issue.
I have several eclipse versions running and have thus put them into
directories like:
C:\eclipse_3.3\<eclipse-as-unzipped>
C:\eclipse_3.4\<eclipse-as-unzipped>
etc.
Things are becoming a bit cumbersome, if one can't even add such a short
prefix any more. Developers shouldn't use that limit up to the last
character, but allow for at least 20 or so characters left. Or else
making a backup of an eclipse folder to directories that contain e.g. a
date as part of the filename becomes impossible.
IMHO the eclipse projects should start thinking about a different naming
scheme anyway. I mean: combining full package-names, version and build
numbers up to 4 levels deep and ranging in the hundreds (like
v1.2.30.400), dates or sometimes timesstamps with minutes and even
seconds plus sometimes even additional hashes (or whatever that
gobledygook at the end of some filename is) into filenames and then
wrapping such files again in directories (maybe even nested several
times) with similar convoluted names at some points simply overdoes it.
While such a limit is certainly annoying and not exactly "adequate for a
modern OS" any more, to be honest - I think it's not the most stupid
thing that Windows puts at least *some* limit to this kind of nonsense!
Not far the day, I guess, when we will have to define different drives
(C:\eclipse, D:\eclipse\, ...) to be able install different eclipse
versions. ||-(
Michael
|
|
|
| Re: Unzipping eclipse download requires password?!? [message #330752 is a reply to message #330735] |
Tue, 12 August 2008 15:40 |
Eclipse User |
|
|
|
Originally posted by: zx.code9.com
Michael Moser wrote:
> Not far the day, I guess, when we will have to define different drives
> (C:\eclipse, D:\eclipse\, ...) to be able install different eclipse
> versions. ||-(
You know, you can always install Linux, I hear the cool kids use that
these days ;)
Cheers,
~ Chris
|
|
|
| Re: Unzipping eclipse download requires password?!? [message #330758 is a reply to message #330735] |
Tue, 12 August 2008 16:04 |
| Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
Michael Moser wrote:
> Eric Rizzo wrote:
>>> ...
>> This wiki page,
>> http://wiki.eclipse.org/SDK_Known_Issues#Windows_issues explains the
>> problems with unzipping on Windows. There is a link to that page on
>> the main packages downloads page, but not for some reason on the page
>> you were looking at, http://www.eclipse.org/downloads/packages/ I've
>> re-opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=169776 to
>> (hopefully) correct that.
>> Hope this helps,
>> Eric
>
> Thanks - it did help. Except for the path issue.
> I have several eclipse versions running and have thus put them into
> directories like:
>
> C:\eclipse_3.3\<eclipse-as-unzipped>
> C:\eclipse_3.4\<eclipse-as-unzipped>
> etc.
>
> Things are becoming a bit cumbersome, if one can't even add such a short
> prefix any more. Developers shouldn't use that limit up to the last
> character, but allow for at least 20 or so characters left. Or else
> making a backup of an eclipse folder to directories that contain e.g. a
> date as part of the filename becomes impossible.
I use a structure like this on Windoze XP and 2000 without any problems:
D:\
Java\
Eclipse\
3.3\
3.4\
workspaces\
Also, see this bug report for some debate about what to do with this
issue in general:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=166597
>
> IMHO the eclipse projects should start thinking about a different naming
> scheme anyway. I mean: combining full package-names, version and build
> numbers up to 4 levels deep and ranging in the hundreds (like
> v1.2.30.400), dates or sometimes timesstamps with minutes and even
> seconds plus sometimes even additional hashes (or whatever that
> gobledygook at the end of some filename is) into filenames and then
> wrapping such files again in directories (maybe even nested several
> times) with similar convoluted names at some points simply overdoes it.
>
> While such a limit is certainly annoying and not exactly "adequate for a
> modern OS" any more, to be honest - I think it's not the most stupid
> thing that Windows puts at least *some* limit to this kind of nonsense!
>
> Not far the day, I guess, when we will have to define different drives
> (C:\eclipse, D:\eclipse\, ...) to be able install different eclipse
> versions. ||-(
>
> Michael
>
|
|
|
| Re: Unzipping eclipse download requires password?!? [message #330876 is a reply to message #330735] |
Thu, 14 August 2008 21:35 |
| Eclipse User |
|
|
|
Originally posted by: eclipseng.arthorne.com
Michael Moser wrote:
> IMHO the eclipse projects should start thinking about a different naming
> scheme anyway. I mean: combining full package-names, version and build
> numbers up to 4 levels deep and ranging in the hundreds (like
> v1.2.30.400), dates or sometimes timesstamps with minutes and even
> seconds plus sometimes even additional hashes (or whatever that
> gobledygook at the end of some filename is) into filenames and then
> wrapping such files again in directories (maybe even nested several
> times) with similar convoluted names at some points simply overdoes it.
The rant is well taken, and we have been working towards making those
paths shorter. The Eclipse SDK for example now has a longest path
length of 121, as opposed to 169 in the 3.3.2 release. This is still
long, but on a system with a 255 character limit it should allow for
another 134 characters of prefix to be safely added, which is not bad.
There is a bug report about reducing the size of the "gobledygook", but
it is actually quite a difficult problem
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=175714).
However, the real problem you are seeing is because the EMF project has
not switched over to using source bundles (see bug 14872 for a
description of source bundles). They still use source features, which
had the property of creating nested directories with qualifiers and
timestamps and gobledygook. This is the reason you are hitting the path
limit with such a small prefix.
--
|
|
|
| Re: Unzipping eclipse download requires password?!? [message #330878 is a reply to message #330876] |
Thu, 14 August 2008 22:25 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
John,
It's good to know EMF is the real problem. :-P
I think https://bugs.eclipse.org/bugs/show_bug.cgi?id=14872 is a stray
pointer though. Is there something more specific I should look at? I
wonder if Nick is aware that there is a new improved way to do
something? I, added him to the CC list, though he's on vacation right
now.
I'm not aware of any enhancement requests to change how source plugins
are packaged. I suppose that's common knowledge, but it's the first
I've heard about it...
John Arthorne wrote:
> Michael Moser wrote:
>> IMHO the eclipse projects should start thinking about a different
>> naming scheme anyway. I mean: combining full package-names, version
>> and build numbers up to 4 levels deep and ranging in the hundreds
>> (like v1.2.30.400), dates or sometimes timesstamps with minutes and
>> even seconds plus sometimes even additional hashes (or whatever that
>> gobledygook at the end of some filename is) into filenames and then
>> wrapping such files again in directories (maybe even nested several
>> times) with similar convoluted names at some points simply overdoes it.
>
> The rant is well taken, and we have been working towards making those
> paths shorter. The Eclipse SDK for example now has a longest path
> length of 121, as opposed to 169 in the 3.3.2 release. This is still
> long, but on a system with a 255 character limit it should allow for
> another 134 characters of prefix to be safely added, which is not bad.
> There is a bug report about reducing the size of the "gobledygook",
> but it is actually quite a difficult problem
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=175714).
>
> However, the real problem you are seeing is because the EMF project
> has not switched over to using source bundles (see bug 14872 for a
> description of source bundles). They still use source features, which
> had the property of creating nested directories with qualifiers and
> timestamps and gobledygook. This is the reason you are hitting the
> path limit with such a small prefix.
> --
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Unzipping eclipse download requires password?!? [message #330882 is a reply to message #330878] |
Thu, 14 August 2008 23:51 |
Steve Blass
Messages: 276
Registered: July 2009 |
Senior Member |
|
|
I've downloaded and unpacked the Ganymede modeling package on a few
machines now and there's only one file that WinZip won't unpack into
c:\eclipse34modeling\ on XP for me.
" eclipse\plugins\org.eclipse.uml2.diagram.examples.clazz_0.8. 0.v200806112132\diagram\07-02-03\09
Composite Structures\Figure 9.11 - The internal structure of the
Observer collaboration shown inside the collaboration
icon.umlcompositesitestructures_diagram"
The things I use seem to work fine without it.
-
Steve
Ed Merks wrote:
> John,
>
> It's good to know EMF is the real problem. :-P
>
> I think https://bugs.eclipse.org/bugs/show_bug.cgi?id=14872 is a stray
> pointer though. Is there something more specific I should look at? I
> wonder if Nick is aware that there is a new improved way to do
> something? I, added him to the CC list, though he's on vacation right now.
> I'm not aware of any enhancement requests to change how source plugins
> are packaged. I suppose that's common knowledge, but it's the first
> I've heard about it...
>
>
> John Arthorne wrote:
>> Michael Moser wrote:
>>> IMHO the eclipse projects should start thinking about a different
>>> naming scheme anyway. I mean: combining full package-names, version
>>> and build numbers up to 4 levels deep and ranging in the hundreds
>>> (like v1.2.30.400), dates or sometimes timesstamps with minutes and
>>> even seconds plus sometimes even additional hashes (or whatever that
>>> gobledygook at the end of some filename is) into filenames and then
>>> wrapping such files again in directories (maybe even nested several
>>> times) with similar convoluted names at some points simply overdoes it.
>>
>> The rant is well taken, and we have been working towards making those
>> paths shorter. The Eclipse SDK for example now has a longest path
>> length of 121, as opposed to 169 in the 3.3.2 release. This is still
>> long, but on a system with a 255 character limit it should allow for
>> another 134 characters of prefix to be safely added, which is not bad.
>> There is a bug report about reducing the size of the "gobledygook",
>> but it is actually quite a difficult problem
>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=175714).
>>
>> However, the real problem you are seeing is because the EMF project
>> has not switched over to using source bundles (see bug 14872 for a
>> description of source bundles). They still use source features, which
>> had the property of creating nested directories with qualifiers and
>> timestamps and gobledygook. This is the reason you are hitting the
>> path limit with such a small prefix.
>> --
|
|
|
| Re: Unzipping eclipse download requires password?!? [message #330884 is a reply to message #330882] |
Fri, 15 August 2008 00:53 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Steve,
That sounds like https://bugs.eclipse.org/bugs/show_bug.cgi?id=240632.
Steve Blass wrote:
> I've downloaded and unpacked the Ganymede modeling package on a few
> machines now and there's only one file that WinZip won't unpack into
> c:\eclipse34modeling\ on XP for me.
>
> " eclipse\plugins\org.eclipse.uml2.diagram.examples.clazz_0.8. 0.v200806112132\diagram\07-02-03\09
> Composite Structures\Figure 9.11 - The internal structure of the
> Observer collaboration shown inside the collaboration
> icon.umlcompositesitestructures_diagram"
>
> The things I use seem to work fine without it.
>
> -
> Steve
>
>
>
> Ed Merks wrote:
>> John,
>>
>> It's good to know EMF is the real problem. :-P
>>
>> I think https://bugs.eclipse.org/bugs/show_bug.cgi?id=14872 is a
>> stray pointer though. Is there something more specific I should look
>> at? I wonder if Nick is aware that there is a new improved way to do
>> something? I, added him to the CC list, though he's on vacation
>> right now.
>> I'm not aware of any enhancement requests to change how source
>> plugins are packaged. I suppose that's common knowledge, but it's
>> the first I've heard about it...
>>
>>
>> John Arthorne wrote:
>>> Michael Moser wrote:
>>>> IMHO the eclipse projects should start thinking about a different
>>>> naming scheme anyway. I mean: combining full package-names, version
>>>> and build numbers up to 4 levels deep and ranging in the hundreds
>>>> (like v1.2.30.400), dates or sometimes timesstamps with minutes and
>>>> even seconds plus sometimes even additional hashes (or whatever
>>>> that gobledygook at the end of some filename is) into filenames and
>>>> then wrapping such files again in directories (maybe even nested
>>>> several times) with similar convoluted names at some points simply
>>>> overdoes it.
>>>
>>> The rant is well taken, and we have been working towards making
>>> those paths shorter. The Eclipse SDK for example now has a longest
>>> path length of 121, as opposed to 169 in the 3.3.2 release. This is
>>> still long, but on a system with a 255 character limit it should
>>> allow for another 134 characters of prefix to be safely added, which
>>> is not bad. There is a bug report about reducing the size of the
>>> "gobledygook", but it is actually quite a difficult problem
>>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=175714).
>>>
>>> However, the real problem you are seeing is because the EMF project
>>> has not switched over to using source bundles (see bug 14872 for a
>>> description of source bundles). They still use source features,
>>> which had the property of creating nested directories with
>>> qualifiers and timestamps and gobledygook. This is the reason you
>>> are hitting the path limit with such a small prefix.
>>> --
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
Goto Forum:
Current Time: Thu Dec 26 10:09:31 GMT 2024
Powered by FUDForum. Page generated in 0.06752 seconds |
] 
Search
Help
Register
Login
Home
